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FOREWORD 


This document presents the flight test requirements for the Initial Synthetic Vision 
Systems Integrated Technology Evaluation Flight Test to be flown aboard NASA 
Langley’s ARIES aircraft and the final hardware architecture implemented to meet these 
requirements. Part I of this document contains the hardware, software, simulator, and 
flight operations requirements for this flight test as they were defined in August 2002. 
The contents of this section are the actual requirements document that was signed for this 
flight test. As such, the section headings, content and formatting follow the guidelines as 
defined in Langley Management System (LMS-CP-0960) procedure for conducting 
research aboard a NASA Langley aircraft. Part II of this document contains information 
pertaining to the hardware architecture that was realized to meet these requirements as 
presented to and approved by a Critical Design Review Panel prior to installation on the 
B-757 Airborne Research Integrated Experiments Systems (ARIES) airplane. This 
information includes a description of the equipment, block diagrams of the architecture, 
layouts of the workstations, and pictures of the actual installations. 
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1. REVISION CONTROL TABLE 


Version 

Date 

Author & Description 

1.0 

4/29/02 

Lynda Kramer. Baseline document. 

2.0 

6/13/02 

Lynda Kramer. Incorporated SRR panel member comments. 

Replaced pilot-not-flying display (PNFD) references with synthetic vision auxiliary 
display (SVAD). 

Removed requirement for use of new Data Acquisition System (Updated 4-20). 

Removed Requirement for Technology Transfer Area modifications (Deleted 4-85, 4- 
86). 

Removed requirements from Appendices and placed them in body of document 
(Deleted Appendix 9. 2-9. 5; updated 4-7, 4-8, 4-14, 5-2). 

Updated 9.1 Appendix A acronym list. 

Updated Section 7 formatting to indicate requirements in this section. 

Made sure only requirements were enumerated in Sections 4-7 (Reformatted 4-38, 4- 
53, 4-81, 4-96 as these were not requirements). 

Updated Video Requirements (Updated Table 4.7, 4-98, Added 4-91 and 4-92). 

Incorporated DIME changes given by PI. Updated Figure 4.14. Revised 4-67, 4-69, 

4- 71 and omitted 4-73. Table 4.1, removed “ALTM Control Device”. Table 4.2, 
"Terrain Database Integrity” is a unit-less value (1, 0, -1), removed desired and 
acceptable resolution requirements. Table 4.2, “Terrain Database Integrity (RMS)” 
does have units of meters-squared. Desired and acceptable resolution requirements 
were listed here (0.01, 0.1). Section 7-11 (System Validation Requirements), 
removed (3) Calibration of ALTM orientation. 

Removed FDI CCD camera requirements (Deleted 4-55&4-56, updated Fig. 4.8). 

Incorporated RIPS changes given by PI. Updated Figures 4.1 and 5.2. Removed 
cockpit speaker requirement (Figure 4.1, Table 4.1, Figure 4.1 1, omitted 4-90, omitted 

5- 6, 6-19). Removed requirement that RIPS audible alerts be generated from the 
Onyx (Figure 4.1, Figure 4.11, 4-89, omitted 5-6, 6-19, omitted 6-31). Updated Table 
4.3. Revised requirements under Section 7.3 to reflect that ADS-B data needs to 
include altitude information. Revised requirements under section 7.4 to reflect 
potential use of non-Langley aircraft. Added 1030/1090 data link requirement (Figure 
4.1, Table 4.1, Figure 4.11, 4-53). 

Incorporated changes given by SVS Chief Scientist. Updated Goals and Objective 
Section and SV Sensors description under section 5.1.1. Updated Figure 4.2, Figure 
4.5, Figure 4.6, Figure 4.7, Figure 4.10, 4-29. Updated requirements to indicated 
need for ethernet connection between pallets so R-C could use aural warnings output 
from SVS ND computer (Updated 4-22, added new requirement 4-23, deleted 4-51). 
Added FUR pod alignment and image scaling under Sections 7.3 and 7.16. Moved 
reqts 4-45-46, 4-48-449 to Section 4.1.2. 

Replaced 1U computer references with 2U computer (Figure 4.4). 

Incorporated changes given by SV Sensor PI. Replaced Figure 4.13. 
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Version Date Author & Description 

2.1 6/28/02 Lynda Kramer. Replaced Figure 4.14 to show following changes: 1)using TBD for 

pallets hosting DIME computer and KVM; 2)removed IRIG-B input from 
DIME. computer. 

Removed intercom audio requirement on SV Sensors videotapes (4-86). 

Replaced UAT datalink reference with ADS-B datalink (6-33) 

Relaxed requirement for experimental display recordings in FSIL/RSIL (6-4). 

Replaced RS232 references with Ethernet references (Section 5.1.1 SV Sensors and 
Figure 5.4) 

Modified wording on HUD camera video recording (4-89). 

Identified format for SVAD presentation to jumpseat observer and evaluation pilot 
(added new requirements 4-8 and 4-9). 

Identified push-to-listen function for VRS (added requirement 4-11). 


Updated video distribution paths in Figures (Replaced Figure 4.3, 4.5, 4.6, 4.7, & 
4.10) 


2.2 


7/12/02 


Lynda Kramer. Incorporated Acting Aviation Manager’s comments (4-7, 4-18, 4-29, 
4-69, 4-72, 4-73, 4-84, 4-85, 5-12, 7-11, 7.14, 7-27, 7-25. 7-31). Moved requirement 
4-93 to Section 7.12 (Deleted 4-93 Added 7-30). Added sentence in Section 6.2.2 
that a Pilot Briefing Guide will be provided by InSITE researchers. 


2.3 


7/31/02 


Doug Arbuckle. Corrected statement of certain requirements (“shall") to reflect their 
actual status as recommendations (“should”), reflecting SASA resource constraints 
and INSITE researcher priorities. 


2.4 


8/5/02 


Lynda Kramer. Updated FLIR format references (Replaced Figures 4. 5-4.8, 4.10) 
and audio output to intercom system via the VRS (Replaced Figure 4.1&4.1 1, deleted 
requirement 4-19). Deleted Rockwell Collins removable disk X3 equipment and 
castle switch for HUD declutter (Updated Table 4.1). Refined Section 7.6.and 
prioritized weather conditions. Updated RVR measurement requirement (Updated 7- 
36). Deleted Figure 4.8and reflected this figure deletion in subsequent table 
numbering in Section 4 and in requirement 4-45 (Deleted Figure 4.8; updated 4-45; 
renumbered Tables 4.9-4.14 to Tables 4.8-4.13). 
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3. PROGRAM OVERVIEW 


3.1 General Description 

Limited visibility is the single most critical factor affecting both the safety and 
capacity of worldwide aviation operations. In commercial aviation, over 30-percent 
of all fatal accidents worldwide are categorized as Controlled Flight Into Terrain 
(CFIT), where a functioning airplane is inadvertently flown into the ground, water, or 
an obstacle. Limited visibility and reduced situational awareness are predominant 
causal factors for CFIT accidents. Another type of accident involving restricted 
visibility combined with compromised situational awareness is runway incursions. In 
support of the NASA’s Aviation Safety Program (AvSP), the Synthetic Vision 
Systems (SVS) Project is developing technologies with practical applications that will 
eliminate low^visibility conditions as a causal factor to civil aircraft accidents. SVS 
also seeks to replicate the operational benefits of flight operations in bright, clear, 
sunny day conditions, regardless of the actual outside weather conditions. SVS 
emphasizes the cost-effective use of synthetic/enhanced-vision displays; worldwide 
navigation, terrain, obstruction, and airport databases; Global Positioning System 
(GPS)-derived navigation; and ranging and imaging sensors to eliminate “visibility- 
induced” (lack of visibility) errors for all aircraft categories (transports, General 
Aviation, rotorcraft). 

3.2 Goals and Objectives 

Figure 3.1 illustrates the goals and objectives of the SVS Project (see Reference 1). 
GoaI Eliminate Low-Visibility Induced Accidents 


Objwtfv** 


Challenges 


Approach 


Thrusts 




In all Weather Conditions, Replicate 
the Safety and Operational Benefits of 
Clear-Day Flight Operations 


Address Commercial, Business, and 
General Aviation Applications for both 
Existing & Future Cockpits 


Database Development, 
Certification, Maintenance, & 
Real-time Integrity Monitoring 


Certification and NAS 
Integration of Flight Critical 
Synthetic Vision Systems 


Affordable & 
Retrofitable 
Systems 





Accelerate Development of 
Certifiable SVS Database & 
Enhanced Vision Sensors 

Cooperative 
Partnerships with 
Industry, FAA & DOD 

Iterative Development, 
Assessment, & Validation 
of Candidate Concepts 




.... — ... 


Enabling Technologies 
for Synthetic Vision 
Systems 


Commercial & Business 
Aircraft Synthetic Vision 
Systems 


General Aviation 
Synthetic Vision 
Systems 


Figure 3.1. Overview of Synthetic Vision System Project Efforts 
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The goals and objectives of the INitial SVS Integrated Technology Evaluation (InSITE) 
were generated by the SVS flight-test team in response to the SVS Project and 
established project plan and milestones. As such, the primary purpose of InSITE is to 
emphasize the system aspects of the SVS concepts involved. 

Previous SVS Flight Tests (DFW/2000 and EGE/2001) have primarily focused on the 
general use and usefulness of SVS for providing flight critical guidance and improved 
situational awareness. The research objectives of these previous flight tests were focused 
on the SVS display (e.g., size, content, and format) and on SVS enabling technologies 
(e.g., Runway Incursion Prevention System, RIPS; Enhanced Vision System, EVS; and 
database integrity monitoring experiment, DIME). While differential GPS (D-GPS) and 
on-board databases can provide the primary framework for an operational SVS, many in 
the aviation community believe that independent integrity monitors for both surveillance 
and navigational functions will be required to meet certification and safety requirements. 
This functionality will rely heavily on existing on-board sensors (e.g., weather radars, 
high quality radar altimeters) to provide real-time integrity monitoring for the databases. 
Specifically, on-board integrity sensors will provide independent air-to-air, air-to-ground, 
ground-to-ground, and ground-to-air traffic and object surveillance, a runway incursion 
monitor and a confirmation of database integrity and registration (navigational position 
confirmation via terrain feature extraction). Additionally, the requirements for 
augmenting SVS concepts with the independent capabilities of weather-penetrating, 
enhanced vision imaging sensors during low visibility landing and surface operations 
conditions will be explored. These technologies form the basis for monitoring the 
dynamic flight environment and thereby supplement the synthetic world with real-time, 
direct measurement of the surrounding terrain and air/ground traffic. This series of flight 
tests proposes to integrate these enabling technologies into the larger SVS concept 
design, with such a design ultimately being introduced into the commercial air transport 
market. 

The requirements given in this document encompass testing of three SVS systems 
(NASA, BAE Systems, and Rockwell-Collins) as well as four specific NASA SVS 
component technologies (SVDC, RIPS, SV Sensors and DIME). These elements and 
their objectives are described in further detail below. 

NASA SVS 


The NASA SVS encompasses the integration of tactical and strategic Synthetic Vision 
Display Concepts (SVDC) with Runway Incursion Prevention System (RIPS) alerting 
and display concepts, real-time terrain database integrity monitoring equipment (DIME) 
and algorithms, and Enhanced Vision Systems (EVS) and/or improved Weather Radar for 
object detection. 

The NASA SVS objectives are as follows: 
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1. Initial flight test evaluation of integrated tactical and strategic NASA SVS concepts 
intended for commercial and business aircraft in a terrain-challenged operational 
environment. 

2. Flight test evaluation of industry- partner (Rockwell-Collins and BAE Systems) 
integrated tactical and strategic SVS/EVS concepts intended for commercial and 
business aircraft in a terrain-challenged operational environment. 

3. Onboard flight demonstration of integrated tactical and strategic SVS/EVS concepts 
to key industry and government representatives. 

BAE Systems (BAE) SVS 

BAE is defining and developing a cost-effective future transport aircraft flight deck 
information management and display system based on synthetic and enhanced vision 
concepts that will significantly reduce or eliminate visibility- induced accidents; improve 
situational awareness; increase safety; and reduce delays, diversions, and cancellations. 

The BAE objectives are as follows: 

1 . Investigate operational utility and acceptability of enhanced Terrain/Obstacle 
awareness provided by SVS display concepts for approach procedures, including 
approach procedures in a terrain-challenged operational environment. 

a. Usefulness of raster Head-up Display (HUD) Millimeter Wave radar (MMWR) 
image for situational awareness of Pilot Flying (PF); 

b. Usefulness of raster HUD Forward Looking Infra-Red (FLIR) image for 
situational awareness of Pilot Flying; 

c. Usefulness of raster HUD fused MMWR/FLIR image for situational awareness of 
Pilot Flying; 

d. Usefulness of above in absence of basic terrain display primary flight display 
(PFD); 

e. Usefulness of above in conjunction with basic terrain display PFD; 

f Ability of crew to integrate pilot not flying (PNF) monitoring of sensor imagery 
with normal flight deck duties during approach; 

2. Demonstrate runway incursion detection capability of FLIR and MMWR sensors: 

a. Ability of PF to detect runway incursion; 

b. Ability of PNF to detect runway incursion; 

3. Investigate operational improvements available from fusion of FLIR and MMWR 
imagery 

4. Collect subjective opinion on various image processing enhancements 

5. Collect radar data for future algorithm development 
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Rockwell Collins (R-O SYS 


R-C is developing, simulating, and flight testing prototype synthetic vision information 

system (SVIS) displays. The synthetic vision displays include a pathway PFD format, a 

planform and vertical profile map format, and a HUD wireframe terrain format. 

The R-C objectives are as follows: 

1 . Investigate operational utility and acceptability of enhanced terrain awareness of SVS 
display concepts to Required Navigation Performance (RNP) approach procedures in 
a terrain- challenged operational environment. 

a. Assess pilot path control performance during manually- flown landing, 
approach and go-around maneuvers in a terrain-challenged operational 
environment with SVS display concepts using instrument and visual approach 
procedures. 

b. Assess auto-pilot (using ship’s system inputs) monitoring utility and 
operational acceptability of SVS display concepts in a terrain-challenged 
operational environment. 

c. Graphical techniques will be used to show the relationship between Actual 
Navigation Performance (ANP) and RNP including flight technical/systems 
error for both hand flown and auto- flight procedures 

2. Demonstrate integrated terrain, traffic, weather and pathway displays for both surface 
movement and airborne procedures. 

a. Integration of RIPS algorithms with surface guidance (SGS) displays. 

b. Integration of DIME algorithms including trend information for integrity 
monitoring. 

c. Integration of enhanced sensors with fusion integration techniques for both 
FLIR and x-band radar information to include display of object and terrain 
detection with sensors. 

d. Integration and display of combined track information for traffic and other 
objects. 

e. Integration of simulated onboard and datalinked weather in a graphical form. 

f Integration of obstacle data in a graphical form including demonstration of a 
datalinked NOT AM obstacle (simulated). 

g. Integration of SVIS guidance concepts with the MCP and auto- flight system. 

3. Validate SVIS flight deck operational concepts for flight decks with and without a 
HUD. 

4. Evaluate operational systems errors on terrain representations for conformal displays. 

SVDC 


The SVDC provides the human- machine interface to NASA SVS for pilots. Display 
elements include, for example: perspective terrain, flight path guidance, and traffic 
information both in the air and on the surface. These display elements will be presented 
on multiple display surfaces (HUD; PFD; Navigation Display, ND; and Synthetic Vision 
Auxiliary Display, SVAD) for this flight test. SVDC also includes pilot inputs. 
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The SVDC objectives are as follows: 

1 . Investigate operational utility and acceptability of enhanced terrain awareness of SVS 
display concepts to RNP approach procedures in a terrain- challenged operational 
environment. 

a. Assess pilot path control performance during manually- flown landing 
approach and go-around maneuvers in a terrain-challenged operational 
environment, with and without SVS display concepts, and determine the effect 
on that performance of the presence of SVS components. 

b. Assess auto-pilot (using ship’s system inputs) monitoring utility and 
operational acceptability of SVS display concepts in a terrain-challenged 
operational environment 

2. Demonstrate symbology transition strategies on the head-up display, primary flight 
display and the navigation display for air to ground operations and ground to air 
operations. 

3. Evaluate terrain texturing (photorealistic, elevation-based) techniques and viewpoint 
locations (planform, perspective) on the Navigation Display (ND). 

4. Demonstrate methods of presenting database loss- of- integrity alerts to the crew. 

5. Demonstrate methods of iconic presentation of sensor-detected objects (unmapped 
towers, runway and taxiway obstacles, runway confirmation wireframe) from a 
weather radar and/or a FLIR camera into the SVS database presentation. 

6. Demonstrate real-time insertion of iconic objects (e.g. towers, closed runway / 
taxiway) from a NOTAM source (simulated data link) into the SVS database 
presentation. 

RIPS 


The RIPS research system makes use of advanced displays, data links, and GPS to enable 
equipped aircraft to operate at airports independent of visibility while ensuring safety. 
This is done by providing pilots with supplemental situational awareness and guidance 
cues, a real-time display of airport traffic, and alerts of runway incursions and route 
deviations on both a HUD and an electronic moving map (EMM) of the airport. 

The RIPS objectives are as follows: 

1. Demonstrate RIPS integrated with the Synthetic Vision Display Concepts in an 
operational environment 

• Perform selected maneuvers with the test aircraft and equipped vehicles 
(aircraft and/or van acting as incurring traffic) to show how runway incursion 
alerting can eliminate incursion- induced accidents during landing, takeoff, and 
taxi. Surveillance information will be provided by sensor object detection and 
Automatic Dependent Surveillance-Broadcast (ADS-B) sources. 

• Perform selected maneuvers with the test aircraft to show how tactical and 
strategic displays can be used to provide enhance situational awareness and 
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guidance in any visibility, thus reducing the likelihood of inadvertent route 
deviation or ownship runway incursion due to blunder during taxi. 

2. Validate proposed operational and technical requirements 

• Compare test data with draft standards and requirements that have been 
generated through analytical and flight simulation activities. The resulting 
data can impact a broad range of requirements from crew roles and 
procedures (i.e. how these displays should be used), to data accuracies, update 
rates, and end-to-end system performance 

3. Assess technology performance 

• Through the collection and analysis of flight test data, assess the capability of 
the ADS-B data link, sensor object detection systems, and onboard incursion 
alerting system to support the system concept and operational requirements. 


DIME 

The DIME subsystem is designed to provide a quantifiable level of htegrity for the 
Digital Elevation Models (DEMs) used by the NASA SVS. In general, this is 
accomplished by performing a real-time comparison of the DEM with measurements 
made by onboard ranging sensors. 

The DIME objectives are as follows: 

1. Characterize the Digital Elevation Model (DEM) integrity monitor’s operational 
behavior using three standard B757 radar altimeters, a weather radar, the standard 
Inertial Navigation System (INS), and a Wide-Area Augmentation System (WAAS) 
receiver. 

2. Assess the quality of multiple DEMs provided by industry and government 
organizations. 

3. Observe the integrity monitor performance in a region characterized by severe terrain 
undulations and in the presence of known and unknown DEM error classes (including 
intentional horizontal and vertical offsets). 

4. Obtain pilot feedback on loss-of- integrity alerts that are generated and presented in 
the flight deck. 

Synthetic Vision (SV) Sensors 

The SV Sensors element is responsible for defining the “research sensor suite” to support 
the NASA SVS. These systems include the weather (WX) radar, FLIR pod, ADS-B, and 
Traffic Alert and Collision Avoidance System (TCAS) hardware, along with the software 
modules and interfaces that will allow for the evaluation of the integrated NASA SVS. 

The SV Sensors objectives are as follows: 

1. Investigate the operational characteristics and compatibility of SV Sensor 
technologies to provide terrain and obstacle information in air-to-air, air-to-ground, 
ground-to-ground, and ground-to-air flight phases. 
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2. Assess the performance of SV Sensor technologies and their ability to supplement the 
SYS concept. 


3.3 Program Hierarchy (Levels I, II, III, IV) 

The SVS Project (see Reference 1) is structured as shown in Figure 3.2. Note: the 
General Aviation sub-element of the project is not participating in the testing 
described in this document. 



• Crew-Centered Display 
Concepts 

• Crew Response 
Evaluation Methodologies 


• General Aviation 
Concept Development 

• Capstone S.E. 

Region 

• Human Centered 
Methodologies 
(Single Pilot) 


• Runway Incursion 
Prevention Technologies 

• SVS Database Technologies 

• SVS Sensor Technologies 

• SVS Integrity 


Figure 3.2. SVS Work Breakdown Structure 


3.4 Requested Facilities 

3.4.1 Aircraft 

The NASA LaRC B-757 ARIES aircraft is required to support the flight-test 
objectives described in this document. Several capabilities are envisioned for 
incorporation of synthetic vision systems for flight-testing in the NASA LaRC 
ARIES aircraft that would have direct applications to current and future transport 
aircraft. 

In addition, this flight project requires the use of other LaRC aircraft equipped with 
ADS-B to enable testing of RIPS functions. These aircraft will also serve to test SV 
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Sensors object detection algorithms. At least one ADS-B equipped aircraft is 
required for both airports (WAL and RNO). The B-200 is requested for RNO and 
WAL. The C-206 is requested for WAL, if available. See Section 7 for more details. 

3.4.2 Ground-based Facilities 

The Flight Systems Integration Lab (FSIL) and/or the Research System Integration 
Laboratory (RSIL) are required to validate the experimental systems. By simulating 
the aircraft systems in flight conditions, data passing through the network devices can 
be monitored, verifying that the test system and data collection is functioning 
properly. The Integration Flight Deck (IFD) is required for pre-flight development 
efforts and for pilot training and familiarization. 

3.5 Key Program/Research Personnel 

Table 3.1. Key Personnel 





1 1 I' { .7 j : . : ; : ' j ' : 7 ?! 7| (ll Jiff 

Mike Norman 

Boeing 

Flight Research 
Coordinator 

757.864.6655 

r.m.norman^larc.nasa.eov 

Randy Bailey 

NASA 

NASA SVS 

Principal 

Investigator 

757.864.8682 

r.e.bailev&darc.nasa.eov 

Lynda Kramer, 
Trey Arthur 

NASA, 

NASA 

SVDC Lead 
Researcher(s) 

757.864.8146 

757.864.6609 

l.i.kramer@larc.nasa.gov 
i .i .arthur@larc.nasa.gov 

Tim Etherington 

Rockwell 

Collins 

Rockwell Collins 
Lead Researcher 

319.295.5233 

319.431.7154 


Dave McKay 

BAE 

Systems 

BAE Systems Lead 
Researcher 

613.592.7400, 
ext 2522 

Dave.Mckav(o).cmcelectix)nics.ca 

Denise Jones 

NASA 

RIPS Lead 
Researcher 

757.864.2006 


Steven Harrah 

NASA 

SV Sensors Lead 
Researcher 

757.864.1805 


Steve Young, 
Maarten Uijt de 
Haag 

NASA, 

Ohio 

Univ. 

DIME Lead 
Researcher(s) 

757.864.1709 

740.593.9562 

s .d. voun£fa).larc .nasa. eov 
uiitdeha@ohiou.edu 

Harry Verstynen 

NASA 

Project Pilot 

757.864.3873 



3.6 Milestones 

Level 1 Milestone (see Reference 3): 

3/03 Simulations & Flight Test Evaluations of Safety-Improvement Systems Wit hin 
AvSP Complete 
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Level II Milestones (see Reference 1): 

6/03 SVS Concepts Initial Flight Evaluation 

Level III Milestones (see Reference 1 and 2): 

12/02 Initial Integrated Retrofit Tactical and Strategic Concept for Surface Ops 
3/03 Phase III Review of Industry Concepts 
9/03 Integrated Retrofit Tactical & Strategic Concepts 
12/02 Integrated Databases Developed for Initial SVS Flight Evaluations 
9/02 Complete Simulation Evaluations of Database Integrity Monitoring Algorithms: 
3/03 Initial Flight Evaluation of Integrated Runway Incursion Prevention and Database 
Integrity Monitoring Concepts 

3.7 Proposed Schedule 

A minimum of 70 flight-hours test program is identified herein starting no earlier than 
February 2003. 

Flight operations requirements are given in Section 7. 

3.8 Requirements Preamble 

Requirements for this program are presented in Sections 4, 5, 6, and 7. For the 
remainder of this document, requirements are separated from the text by sequential 
enumeration for ease of reference during design reviews (e.g., 4-1 is the first 
requirement in Section 4). 

In each of these sections, “shall” indicates a feature that is required, “should” 
expresses a recommendation, “may” provides a permission, and “will” indicates 
something that is part of the system but is not a requirement for a potential developer. 

These requirements have been written for NASA internal use in order to implement 
the proposed systems on NASA research aircraft. Specifically, requirements for 
systems provided by the research team are not described; however, requirements for 
how to implement these systems onto the aircraft are described. 
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4. HARDWARE REQUIREMENTS 

This section describes hardware requirements to implement the three SV systems and 
four SV component technologies on ARIES. Each of these elements has unique 
research objectives and as such, hardware requirements will be described separately. 

Figure 4. 1 provides a block diagram of the key hardware elements and 
interconnections needed on ARIES to enable the flight test. Note: Figure 4.1 should 
not be used as a sole reference for deriving requirements or an implementation. Table 
4.1 and Sections 4.1 to 4.7 are the primary references to be used for these activities. 

4-1. The hardware elements listed in Table 4.1 have been identified as being required 
for research objectives and they shall be installed as presented herein and maintained. 
Note: Flight spares may be provided for hardware elements listed in Table 4.1. 



Figure 4.1. Key Hardware Elements and Interconnections for ARIES 



Part I-Requirements 
Page 17 




































IlllBlBWl 


mmm 

SVS-RD 

Research display (for tactical and strategic head-down concepts) 

NASA/Bailey 

EDCP 

Accepts pilots inputs directed to the EMM and HUD (backup to VRS) 

NASA/Existing 

HUD 

Head-Up display, including HGS-4000 computer, Pilot Display Unit 
and associated electronics and hardware. 

NASA/Existing 

SVAD 

Research display 

NASA/SDB or 
Bailey 

Voice Recognition 
System 

Pilot input device 

NASA/Bailey 



6 ZxlO computers 


2 2U rack computers 


10 VDA 


2 KVM 


8 Video switches 


2 Folsom units 


2 SCRAMNet Quad 
switches 


2 Lightwave video 
extenders 


7 scan converter 


4 video repeater 
displays 


Video mixer 


2 Video mixers 


Scan converter 


Inputs to research displays 


Display control/Data recording/symbology overlay for FLIR 


Video distribution amplifiers 


Keyboard/Video/Mouse control for ZxlOs and 2U computers 


Researcher control of video to display 


Scan convert computer video to RS343(HUD) 



Scan convert displays for ARIES video recording 


Repeat ZxlO displays to pallet operator 


In event that SVRD does not take 2 video inputs 


May be needed to mix FLIR image with computer display 


May be needed to convert ARIES S-video to XGA for SVAD 


NAS A/ Arthur 


NASA/Arthur 


NASA/Arthur 


NAS A/ Arthur 


NASA/Arthur 


NASA/Arthur 


NASA/Arthur 


NASA/Arthur 


NASA/Arthur 


NAS A/ Arthur 


NASA/Arthur 


NAS A/ Arthur 


NASA/Arthur 



MMW radar & R/T 


BAE Radar Image 
Processing computer 


Fuses FLIR and MMW radar 


BAE scan converter Merlin RS- 1 70 to RS-343 scan converter 


Crystal PC CS900 


Radar Data 
Recording Unit 


FLIR video interface 


MMWR digital data recording 


NASA/Arthur 


BAE 


BAE 



Part I- Requirements 
Page 18 


































































Onyx 

RIPS system computer 

NASA/Existing 

WAAS receiver 

Decode GPS corrected signal 

NASA/Existing 

WAAS antenna 

Receive GPS corrected signal-in-space 

NASA/Existing 

AshTech receiver 

Decode GPS signal 

NASA/Existing 

AshTech antenna 

Receive GPS signal- in-space 

NASA/Existing 

VHF receiver 

Decode AshTech GPS correction 

NASA/Existing 

VHF antenna 

Receive AshTech GPS correction signal-in-space 

NASA/Existing 

UAT transceiver 

Decode/Encode Automatic Dependent Surveillance - Broadcast 
(ADS-B) messages 

NASA/Existing 

UAT antenna 

Receive/transmit ADS-B signal-in-space 

NASA/Existing 

1030/1090 

transceiver 

Decode/Encode Automatic Dependent Surveillance - Broadcast 
(ADS-B) messages 

NASA/Existing 

1030/1090 antenna 

Receive/transmit ADS-B signal- in-space 

NASA/Existing 

SCRAMNet ring 

Provide information exchange between the Onyx, SVS PC, the data 
links (FMS/VME), and the data recording system (DAS) 

NASA/Existing 

FMS 

Flight management system 

NASA/Existing 

DAS 

Record test data 

NASA/Existing 

I/O concentrator 

Provide gateway to/from the SCRAMNet ring for GPS and other R- 
757 busses 

NASA/Existing 

DAT drive 

Record playback data and install research software modifications on 
Onyx computer 

NASA/Existing 

Laptops (2) 

RIPS operator interface to Onyx computer 

NASA/Existing 
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Wire Interface Unit 
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WXR-2100 Radar Provide EVS Radar Applications AND Standard WX 


FLIR Pod 


FLIR Control Box 


2 Radar Computers 


Provide LWIR, SWIR, and Visible-Band Imagery 


Provides switching and regulating of FLIR power and signals 


Radar set-up, recording, and produce engineering displays 


2 FLIR Computers FLIR set-up, recording, and produce engineering displays 


RAID Storage 
(8-RHDD) 


2 KVM Switch 


Flat Panel Display 
(RADAR) 


Flat Panel Display 
(FLIR) 


Scan Converter 


3 S-VHS VCRs 


Video switch 


WXI-711 


GPS-LTC time code 
generator 


3 LTC-VITC 
translator 


Storage of FLIR digital video 


Allow one keyboard for each System (Radar and FLIR) 


Display Radar Applications 


Display Radar Applications 


Allow four images to be seen on the one FLIR Flat Panel Display 


Allow recording of NTCS FLIR imagery 


Allows selection of FLIR video for distribution 
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NASA/Harrah 
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NASA/Harrah 
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NASA/Harrah 
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NASA/Harrah 


4.1 Systems/subsystems 


4.1.1 NASA SVS 

The Synthetic Vision System concept, advocated by NASA and followed to varying 
degrees by its industry partners, integrates four component technologies (SVDC, 
DIME, RIPS, and SV Sensors) thereby providing pilots with high- integrity real-time 
geo-referenced information that improves situational awareness with respect to 
terrain, obstacles, traffic, and flight path. Figure 4.2 represents the top-level NASA 
SVS functional design to be implemented for this testing, including relevant elements 
provided by the industry partners, BAE Systems (BAE) and Rockwell Collins (R-C). 
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A/C systems SVS 
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Intercom audio 
EDCP 
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DGPS/WAAS 
ADS-B 
TCAS 
WxR 

NASA FLIR (2) 
FUR pod video 
BAE video 
ARIES video 
ARIES DAS 
SVDC pallet keyboard/mouse 
DIME pallet keyboard/mouse 
SV Sensors pallet keyboard/mouse 
RIPS pallet keyboard/mouse 


Subsystems 


*\ RIPS 


SV Sensors 


SVDC 

~~T~ 


-W DIME 


Functions 

Graphics processing and rendering 
Flight path guidance 
Terrain awareness warning 
Terrain database integrity monitoring 
Taxi monitoring and deviation detection 
Runway incursion detection 
Runway confirmation 
Air-to-ground runway object detection 
Ground-to-ground object detection 
Non-cooperative aircraft tracking 
Multi-target tracking 
Terrain feature extraction 
Voice recognition 
Interfaces 



Display(s) 

HUD 

SVS-RD (PFD) 

SVS-RD (ND) 

SVAD (HUD repeater) 
SVAD (PFD repeater) 
SVAD (ND repeater) 
SVAD (EMM) 

SVAD (FUR) 

ARIES TTA 
ARIES Onyx (VRS) 

ARIES video 
SVDC pallet monitor 
DIME pallet monitor 
SV Sensors pallet monitor 
RIPS pallet monitor 


Figure 4.2. NASA SVS Top-Level Functional Design for RNO/WAL 


4-2. To implement the NASA SVS, all hardware associated with the SVDC, DIME, 
RIPS, and SV Sensors component technologies shall be implemented as specified 
Sections 4. 1 .2, and 4. 1 .5-4. 1 .7. 

4-3. Real-time precision aircraft positioning data shall be provided via Global 
Positioning System data with differential correction and inertial data blending. 
Differential ground stations shall be provided at the different flight test locations as 
identified in Section 7. Differential correction shall be provided at an update rate no 
less than 1 Hz, with inter- sample inertial correction at no less than 50 Hertz, with 
differential correction at ranges no less than 20 nm from the relevant runway 
threshold. The GPS and inertial blending algorithm shall have stability and accuracy 
commensurate to the accuracy of the input data with consistent as well as intermittent 
differential GPS corrections. 

4-4. GPS data shall also be recorded to support post-processing that will result in no 
worse than 10 cm accuracy to evaluate the accuracy of the experimental navigation 
system. 

4-5. The vision restriction device at the flight deck research station (FDRS) used at 
EGE shall be available for this flight test. 
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4-6. The ARIES HUD system (HGS4000 computer, HGS Contro] Panel, overhead 
projector, combiner glass, HUD camera, etc.) used at EGE shall be installed for this 
flight test. 

4-7. A Synthetic Vision Auxiliary Display (SVAD) or displays shall be installed in the 
forward flight deck. The display implementation shall be designed to meet the 
following objectives: 

a) to provide a display for the evaluation of the ability for a pilot not flying to 
integrate monitoring of sensor imagery with normal flight deck duties during 
approach (Note: The pilot referenced here will not be the safety pilot in the right 
seat.); 

b) to provide an enhanced moving map display to provide crew coordination in the 
conduct of evaluations of surface operations (e.g., runway exit selection) using 
alternate modes of the Navigation Display (ND) while the EP has an ND approach 
mode; and 

c) to provide an additional display for FLIR imagery evaluations during final 
approach and surface operations 

A display implementation should be designed to meet the following objective if 
resources permit: 

d) to provide a repeater of the Head-up display to assist in the interpretation of or to 
understand the EP comments from using the HUD, of which only the EP has a view 
from the cockpit. 

4-8. The SVAD presentation to the jumpseat observer, if implemented, should be in a 
landscape format utilizing a 4:3 aspect ratio. 

4-9. The SVAD presentation to the evaluation pilot should be in a landscape format 
utilizing a 4:3 aspect ratio. 

4-10. A Voice Recognition System (VRS) shall be installed on the B757 for use as a 
pilot- vehicle interface in support of SVS display research. The VRS will be provided 
by the researchers. 

4-11. A push-to-listen button accessible to the EP shall be provided to activate the VRS. 

4-12. The Experimental Display Control Panel (EDCP) shall be installed. The EDCP 
may be used primarily or as a backup to the VRS to facilitate pilot control over the 
various research displays. 


Block diagrams of the SVDC and BAE/Rockwell-Collins subsystems are shown in 
Figures 4.3-4.5. (Note: In these figures, a black box indicates existing equipment, a 
blue box indicates new equipment, and a dashed box indicates potentially- needed 
equipment). 

4.1.2 SVDC 

A simplified block diagram of the SVDC subsystem is shown in Figure 4.6. 
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4-13. The NASA- Synthetic Vision Display Concept (NASA-SVDC) requirements shall 
be provided by primarily locating all necessary equipment on a single research pallet, 
analogous to that flown for the SVS-EGE flight test. 

4-14. The NASA-SVDC pallet shall contain three ZxlO computers to provide the 
primary computer graphics output from which to drive the SVS-Primary Flight 
Display (SVS-PFD), the SVS -Navigation Display (SVS-ND), and SVS-Head-Up- 
Display (SVS-HUD). 

4-15. The simplified schematic diagram, shown in Figure 4.3 (with some details 
omitted for clarity), shall be used to implement the NASA SVS-PFD and SVS-ND 
display concepts. Modifications to the schematic to enhance implementation may be 
made upon mutual- agreement. 

4-16. The SVS-PFD and SVS-ND shall be driven from separate computers since the 
integrated SVS display concepts will require terrain portrayal on both the PFD and 
ND which would unduly tax the computer graphics rendering of a single computer. 

4-17. A new Synthetic Vision Systems- Research Display (SVS-RD) will be purchased, 
re-packaged as necessary (subject to the constraint that the new SVS-RD fits within 
the previously used SVS-RD exterior dimensions), and shall be installed in the FDRS 
analogous to how it has been flown previously. The display area of a new SVS-RD 
will consist of two separate LCD panels, each with at least XGA, 1024x768, 
resolution, closely abutted to give a seamless impression. If a suitable SVS-RD 
replacement cannot be found, video mixing shall be required to interface with the 
existing SVS-RD for concept implementation. 

4-18. The NASA SVS-PFD and SVS-ND video shall be continually provided to the 
ARIES video system for distribution and recording (Section 4.7). 

4-19. The SVS-PFD and SVS-ND shall be provided for display on the existing high- 
resolution flat panel displays in the Technology Transfer Area. The SVS-PFD and 
SVS-ND should be provided in their native resolutions to the Technology Transfer 
Area (See Display Requirements, Section 4.5). 

4-20. Video switches shall be provided at the NASA research pallet to select the 
computer graphics input source for the SVS-RD PFD and ND (either R-C/BAE or 
NASA-SVDC). 

4-21. The NASA-SVDC pallet shall contain a quad- switch SCRAMNet Interface to 
provide communication between the NASA ZxlO Personal Computers (PCs) and the 
SGI-Onyx computer on-board the ARIES (not shown in Figure 4.3). SCRAMNet 
data requirements are given in Section 5.2. 

4-22. A 2U-sized PC computer shall be ruggedized and installed on the NASA-SVDC 
pallet. This ruggedized PC (see Figure 4.4) will be used for Graphical-User Interface 
(GUI) controls of the NASA ZxlO computers and direct PC data recording. The 2U 
computer shall be connected to the airplane’s ethemet network. 

4-23. All computers shall have switch-able keyboard, video, and mouse connections to 
allow researcher access to each of the four computers from one seat at the pallet. 
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4-24. All computers contained in the NASA-SVDC and R-C/BAE pallets shall be 
linked by Ethernet connection (not shown in Figures 4.3 or 4.4) 

4-25. Any computer in either the NASA-SVDC pallet or the R-C/BAE pallet shall be 
able to connect (via Ethernet) to any other computer in the two pallets. 

4-26. The schematic diagram, shown in Figure 4.5 (with some details omitted for 
clarity), shall be used to implement the NASA SVS-HUD display concepts. 
Modifications to the schematic to enhance implementation may be made upon 
mutual-agreement. 

4-27. One ZxlO PC on the NASA-SVDC pallet shall be used to generate raster and 
raster symbology for NASA’s SVS-HUD concept as a raster input, through a Folsom 
scan converter, to the HGS-4000 Head-Up Display. This PC shall also be used to 
control the Folsom via RS-232 serial line for proper scan conversion of the input 
source and output. 

4-28. The NASA SVS-HUD shall be continually provided to the ARIES video system 
for distribution and recording. 

4-29. Video switches shall be provided at the NASA research pallet to select the 
computer graphics input source for the Folsom (either R-C/BAE ZxlO HUD or 
NASA-SVDC HUD). 

4-30. Further, the capability to switch the input source to the HGS-4000 raster input 
shall be provided at the NASA pallet. This switch may be made by either a BNC 
connector change or through a video switching unit. The input source to the HGS- 
4000 shall either be an RS-343 format FLIR signal from the SV Sensors pallet, the 
output of the Folsom scan converter at the NASA-SVDC pallet, or the converted RS- 
343 output of the BAE image fusion processor (see Section 4.1.3). 

4-31. The video input to the Folsom, for mixing with the 2U Rack computer graphics 
should be switch- able at the NASA pallet between the BAE image fusion output and 
the SV Sensors NASA FLIR-only video available at the NASA pallet. 

4-32. The video source available to the SVAD as a result of this mixing shall be 
available for video recording and distribution throughout ARIES and shall also be 
available for display at the R-C/BAE pallet. 

4-33. The SVAD shall have available for selection the requisite number of video 
sources required to meet 47. Source selection shall be available in the Forward 
Flight deck. 

4-34. The other SVAD video source shall include, as a minimum, the EMM (RIPS) 
display generated by the SGI- Onyx computer (see Section 5.1.1). Other video 
sources may also be provided subject to resource availability and INSITE researcher 
priorities. 
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Figure 4.3. SVS-PFD and SVS-ND Display Concept Schematic Diagram 
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Figure 4.4. 2U PC Computer NASA-SVDC Concept Schematic Diagram 
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Figure 4.5. SV-HUD Concept Schematic Diagram 
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Figure 4.6. SVDC Subsystem 


4.1.3 BAE Systems SVS 

A simplified block diagram of the BAE subsystem is shown in Figure 4.7. 

4-35. The BAE System SVS requirements shall be met by primarily locating all 
necessary equipment on a single research pallet, combined with R-C pallet 
requirements, analogous to that flown for the SVS-EGE flight test. 

4-36. The R-C/BAE pallet shall contain three ZxlO computers to provide the primary 
computer graphics output from which to drive the Primary Flight Display (R-C/BAE- 
PFD), the Navigation Display (R-C/BAE-ND), and Head- Up- Display (R-C/BAE- 
HUD). In the BAE concept, raster symbology is not required for the HUD and so 
only 2 of the 3 ZxlOs are utilized. The ZxlO computers may have removable or 
separate hard disks to facilitate transition and partitioning between the two CRA 
partners. 

4-37. The simplified schematic diagram, shown in Figure 4.3 (details omitted for 
clarity), shall be used to implement the R-C/BAE PFD and ND display concepts. 
Modifications to the schematic to enhance implementation may be made upon 
mutual- agreement. 

4-38. The R-C/BAE-PFD and RC/BAE-ND shall be driven from separate computers 
and presented on the new SVS-RD, if installed. 
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4-39. The R-C/BAE-PFD and RC/BAE-ND shall always be provided to the ARIES 
video system for distribution and recording (Section 4.7). 

4-40. The R-C/BAE-PFD and R-C/BAE-ND shall be provided for display on the 
existing high- resolution flat panel displays in the Technology Transfer Area. The R- 
C/BAE-PFD and R-C/BAE-ND should be provided in their native resolutions to the 
Technology Transfer Area (See Display Requirements, Section 4.5). 

4-41 . A BAE Radar Imaging Processing Computer shall be installed for the flight test. 
See Reference 7. 

4-42. If radar altitude is not available over the ARINC 429 channel, then the radar 
altitude data shall come from the Radar Altimeter (analog option). If the analog 
option is used, then the following range/resolution based upon radar altitude (see 
reference 7) shall be used: 

For altitudes 0 to 480 ft, Vo = 0.02 x (H + 20) 
where: Vo = dc analog voltage output in volts 
0.02 = dc voltage per foot of altitude 
H = altitude in feet 

20 = altitude in feet at 0 ft altitude indication (-20 ft = 0.0 VDC) 

For altitudes 480 ft to 2500 ft, Vo = 10 x ln(H + 20) - 52.1461 
where: In = natural logarithm 

4-43. In addition to the ZxlO computers on the R-C/BAE pallet, the following 
equipment as specified in Reference 7 shall be installed: 

• Crystal PC CS900 Industrial computer chassis; - takes up 1/2 of 19 rackmount 
tray in width, 17" of rack space (in height), has 8 PCI slots. 
(http://www.crystalpc.com/products/computers/cs900.asp) 

Single Board Computer for above, e.g. Crystal Flex370 BX, comes with 500- 
MHz to 1 GHz PIII, VGA, Ethernet, Ultra2-Wide SCSI, IDE, USB. 
(http://www.crvstalpc.com/products/computers/cpucards.asp) 

Digital RADAR data acquisition over RS422 via Matrox Genesis card 
(http://www.matrox.com/imaging/products/genesis/home.cfin) 

- ARINC 429 card (SBS tech or Condor) for ARINC 429 acquisition 
(http://209.85. 1 91.21 2/computer/products/product-details.asp) 

- GPS card and Brandywine Communication time card for timestamping of data 

• Radar Data Recording Unit - 19in rack mounted 14” high, 20 ” in deep (approx), 
contains multiple removable hard drives 

• Merlin scan converter 

4 . 44 . A BAE Millimeter Wave Radar (MMWR) shall be installed on the weather radar 
pedestal bulkhead. Refer to Reference 6 . This installation should not interfere 
mechanically with either the present ILS antennas or the X-Band weather radar 
installed on ARIES. 
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A new radome, with X-Band and MMWR transmissivity characteristics, will be 
provided for installation. This radome will be flight-qualified by its manufacturer. 

4-45. FLIR and MMWR signal routing shall be provided in accordance with the 
schematic diagram of Figures 4.5 and 4.7. 

4-46. The schematic diagram, shown in Figure 4.5 (with some details omitted for 
clarity), shall be used to implement the BAE SVS-HUD display concept. 
Modifications to the schematic to enhance implementation may be made upon 
mutual- agreement. 

4-47. The BAE SVS-HUD concept will be created by fusion of MMWR and FLIR 
sensor inputs. This fused imagery shall be provided for display on the R-C/BAE 
pallet, as the raster input source to the HGS-4000 computer, and on the ARIES video 
distribution and recording system. Scan conversion of the fusion RS-170 video to an 
RS-343 format shall be provided before routing to the HGS-4000 computer. 

4-48. A 2U-sized PC computer shall be ruggedized and installed on the R-C/BAE 
pallet. 

4-49. The simplified schematic diagram, shown in Figure 4.8 (with details omitted for 
clarity), shall be used to implement the Synthetic Vision Auxiliary Display (SVAD) 
concepts. 

4-50. The 2U-sized Rack Computer shall generate computer graphics for combination 
with a video signal by a video mixing unit. 

4-51 . The R-C/BAE pallet shall contain a quad-switch SCRAMNet Interface to provide 
communication between the ZxlO PCs and the SGI-Onyx computer on-board the 
ARIES (not shown in Figure 4.3). SCRAMNet data requirements are given in 
Section 5.2. 

4-52. All computers shall have switch-able keyboard, video, and mouse connections to 
allow researcher access to each of the four computers from one location at the pallet. 
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Figure 4.7. BAE Subsystem 



Figure 4.8. SVAD Concept Schematic Diagram 
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4.1.4 Rockwell Collins SVS 

A simplified block diagram of the R-C subsystem is shown in Figure 4.9. 

4-53. The Rockwell Collins SVS requirements shall be met by primarily locating all 
necessary equipment on a single research pallet, combined with BAE pallet 
requirements, analogous to that flown for the SVS-EGE flight test. 

R-C SVS requirements will principally be met by implementation of requirements 
already specified for NASA and BAE Systems SVS in Section 4.1.2 and Section 
4.1.3, respectively. 

4-54. R-C/BAE ZxlO HUD computer graphics shall be mixed with NASA FLIR in a 
RS-343 format and shall be distributed for recording, display at the pallet, and as a 
raster input for the HGS-4000. 


R-C Display Architecture 

R-C/BAE Pallet 



Figure 4.9. R-C Subsystem 


4.1.5 RIPS 

A block diagram of the RIPS system is shown in Figure 4.10. 
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Figure 4.10. RIPS Hardware Architecture 


4-55. ADS-B messages shall be transmitted and received via both UAT and 1030/1090 
data links. 

4-56. The EDCP shall be used to provide pilot inputs to the RIPS. An interchangeable 
faceplate for the EDCP shall be installed with the labels shown in Figure 4. 1 1 cut into 
the plate and backlit (see note). The baseline button labels shall not be displayed 
when the EMM is enabled. Since the baseline buttons labeled F/D, STAR, WXR, and 
TNAV currently serve no function, these button labels shall not be displayed at any 
time. Requirements 4-57 to 4-62 pertain to the EDCP. 

Note: Figure 4.1 1 shows the panel layout used for the March 2002 RIPS simulation. 
Labeling changes may be made based on simulation results and SVS integration. 
Changes, if required, will be determined at a later date. New faceplates would have 
to be fabricated. 

4-57. The button light bar shall be illuminated for the following buttons indicating the 
corresponding function is enabled: RI, PLAN, LAHSO, EMM, ATC, OBST, and 
TERR. 

4-58. The button light bar shall not be used for the following buttons: EX/NXT, 

EX/PRV, ATC/UP, ATC/DN, TAG, SNAP, and DCLTR. 
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4-59. When the EMM mode is disabled, the left knob positions shall retain their 
baseline functionality. 

4-60. When the EMM mode is enabled, rotating the left knob shall change the scale of 
the EMM as follows: 5- zoom level 5x, 10- zoom level 4x, 20- zoom level 3x, 40- 
zoom level 2x, 80- zoom level lx, 160- zoom level 5NM, 320- zoom level OVR. 

4-61. All positions on the right knob shall maintain baseline functionality. Note: If the 
EDCP is used as a backup to the VRS, this knob shall be used for selection of field of 
view on the PFD. 



Figure 4.11. EDCP Panel Layout 


4.1.6 SV Sensors 

A block diagram of the SV Sensors subsystem is shown in Figure 4.12. 
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Figure 4.12. Synthetic Vision Sensors Hardware Architecture 


4-62. A new radar transceiver/antenna shall be installed as a direct replacement of the 
current research radar/antenna. No wiring changes are expected between the radar 
and Pallet 18. 

4-63. Changes to the existing wiring in Pallet 18 and the addition of wiring from Pallet 
18 to the ARIES Onyx, DIME, R-C/BAE, and SVDC computers shall be made h 
accordance with Figure 4.12. 

4-64. The FLIR pod will be qualified for flight in expected icing conditions and shall be 
reinstalled with the addition of a fiber optics transceiver in the forward electronics 
bay and at Pallet 1 8. 

4-65. Additional wiring, along with a reconfiguration of the existing wiring, shall be 
done at Pallet 18 to support EVS displays for the HUD and/or head-down display 
(HDD). 

4.1.7 DIME 

A block diagram of the DIME system is shown in Figure 4.13. Note: Power 
interfaces are not shown. 
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Figure 4.13. DIME Hardware Architecture 


4-66. The DIME hardware elements listed in Table 4.1 shall be installed and 
maintained. Pictures, drawings, and specifications for all elements are available on 
request. Note: the components listed at Pallets 2 and 7A were previously flown for a 
DIME experiment at EGE; no change for these elements or their interfaces is required 
for this testing. 

4-67. The interface shown in Figure 4.13 between the DIME computer and SVDC/R-C 
computers shall be constrained as follows: SVDC/R-C computers shall receive DIME 
data via SCRAMNet. The DIME computer shall produce data intended for SVDC/R- 
C computers via an A-429 output port. SDB is responsible for defining the 
intermediate system responsible for transferring this A-429 data onto the 
SCRAMNet. Specification of this data is available on request. 

4-68. The Airborne Laser Terrain Mapping (ALTM) sensor unit should be installed 
such that the view-port is as close as practicable to aircraft centerline (buttline 0.0) 
and at a body station as close as practicable to that of the radar altimeter antennas. 
The actual location of the ALTM sensor and its associated GPS antenna, in aircraft 
coordinates (STA, BL, WL) within +/- 0.39 inches, shall be provided to the DIME 
researchers prior to the flight-testing accurate to 1 cm or better. The GPS antenna 
that is selected to interface with the ALTM shall be subject to manufacturer 
acceptability. 


Part I- Requirements 
Page 35 


4-69. Mounting shall ensure that the ALTM scanning axis is coincident with the aircraft 
body roll axis to within less than one degree. The actual orientation of the ALTM 
sensor, with respect to the aircraft body axes, shall be provided to the DIME 
researchers prior to the flight- testing. 

4-70. The ALTM view-port should be designed with the following considerations: 

a. Maximum azimuth scanning range for the ALTM is +/- 20 degrees; a 
view-port design that results in less than +/- 20 degrees scanning range 
may be acceptable contingent on approval by the DIME lead researcher; 

b. Although desirable, it is not required that the view-port size accommodate 
the ALTM video camera lens; 

c. If the ALTM view-port design includes a window that the laser must pass 
through while activated, a window/glass material shall be selected that 
ensures adequate transmissivity of the laser energy. 

d. If a motorized shutter is implemented to protect the glass during runway 
operations and/or inclement weather, a shutter control mechanism (e.g. 
switch) and shutter position indicator (e.g. open/closed LED) shall be 
provided at the pallet hosting the DIME computer keyboard, mouse, and 
monitor. 

4-71. The ALTM 8- mm tape drive should be accessible during flights; however, it is 
anticipated that the installation design for the computer rack that hosts the tape drive 
may call for installation in the cargo area beneath the cabin. This is an acceptable 
alternative assuming the tape drive is accessible within 30 minutes before and after 
flights in order to change tapes. 

4-72. A bi-static GPS system, including top and bottom mounted antennae, should be 
installed. This unit is not part of the operational real-time DIME system but is being 
evaluated as a potential low-cost terrain- mapping sensor. 

4.2 Provider(s) 

Refer to Table 4.1. 

4.3 Hardware Interfaces 

Refer to Section 4. 1 . 

4.3.1 Power 

4-73. Power shall be provided to meet the operational requirements of each hardware 
element described in section 4. 1.1 -4. 1.7. 

4.3.2 Environmental 

4-74. Environmental protection shall be provided for each hardware element described 
in section 4. 1.1 -4. 1.7. This includes assuring that the equipment is operated in an 
environment consistent with manufacturer specifications for thermal, vibration, 
pressure, and EMI limits. 
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4.3.3 Structural 

No additional requirements beyond basic aircraft. 

4.3.4 Location 

4-75. The NASA pallet and the R-C/BAE pallet shall be positioned as close to each 
other as feasible. 


4.4 Measurements Requirements 

4.4.1 Table of parameters, limits, units, accuracies, resolutions, and 
sample rates 

4-76. The SCRAMNet parameters listed in Tables 4.2 and 4.3 and the ARINC 429 
parameters listed in Tables 4.4, 4.5, and 4.6 shall be provided at the rates and 
resolutions listed. 

4-77. The brightness and contrast control settings for the HGS-4000 shall be available 
at the SGI-Onyx for recording and real-time de-bugging. 

4-78. The SCRAMNet parameters, Terrain Database Integrity and Terrain Database 
RMS, listed in Table 4.2 shall have the following attributes: 

Parameter: Terrain Database Integrity 
Desired Update Rate: 1 Hz 
Acceptable Update Rate: 1 Hz 
Type: Signed Integer 

Range: -1 (Not Available), 0 (Nominal), +1 (Loss of Terrain Database Integrity) 


Parameter: Terrain Database RMS 
Desired Update Rate: 1 Hz 
Acceptable Update Rate: 1 Hz 
Type: Float 
Range: >0 

Units: meters- squared 

Desired Resolution: 0.01 meters- squared 

Acceptable Resolution: 0.1 meters- squared 


Table 4.2. SCRAMNet Requirements for SVDC 




i §§gjj| 
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Display Parameters 




Aircraft Angle of Attack, Degs 

>60Hz 

>30Hz 

<.05° 

<.1° 

Aircraft Sideslip Angle, Degs 

>60Hz 

>30Hz 

<.05° 

<1° 

Aircraft Flight Path Angle, Degs 

>60Hz 

>30Hz 

<.05° 

<1° 

Aircraft Ground Speed, kts 

>10Hz 

>5Hz 

<.5 kts 

<1.0kts 

Aircraft Indicated Airspeed, kts 

>10Hz 

>5Hz 

<0.5 kts 

<1.0kts 
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Aircraft Landing Capabilities (Cat I, etc.) 


Aircraft Longitudinal acceleration 
along flight path, G’s 


Aircraft Magnetic Heading, Degs 


Aircraft True Heading, Degs 


Aircraft Magnetic Track Angle, Degs 


Aircraft True Track Angle, Degs 


Aircraft Pressure Altitude, ft 


Aircraft Radio Altimeter Altitude, ft 


Aircraft True Airspeed, kts 


Aircraft Vertical Speed, ft/min 


Aircraft VF (Max flap speed), kts 


Aircraft Vmin (Min approach speed), kts 


Aircraft VNE (Never exceed speed), kts 


Aircraft VR (Takeoff Rotate speed), kts 


Aircraft VS (Stall speed), kts 


Aircraft VI (Takeoff decision speed), kts 


Aircraft V2 (Takeoff safety speed), kts 


Baro Setting, In of Hg 


DME - Distance from Nav Device, nm 


EDCP Parameters 


Flap Status, Degs 


Ship-System: 


Flight Director (FD) Status 


FD Acceleration Command 


FD Pitch Command (Degs) 


FD Roll Command (Degs) 


FD Speed Command (kts) 


FD Yaw Command (Degs) 


Experimental System: 


Flight Director (FD) Status 


FD Acceleration Command 



<0.01 G’s <0.02G’s 


>60Hz 


>60Hz 


>60Hz 


>60Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>10Hz 


>lHz 


>10Hz 


>10Hz 


> 


>30Hz 


>30Hz 


>30Hz 


>30Hz 


>5Hz 


>5 Hz 


>5Hz 


>5Hz 


>5Hz 


>5 Hz 


>5Hz 


>5 Hz 


>5 Hz 


>5Hz 


>5Hz 


>lHz 


>5 Hz 


>5Hz 


<.05° 


<.05° 


<0.05° 


<0.05° 


<5 ft 


<5 ft 


<0.5 kts 


<1 ft/min 


<.5 kts 


<.5 kts 


<.5 kts 


<.5 kts 


<.5 kts 


<.5 kts 


<.5 kts 


< 1 ° 


< 1 ° 


< 0 . 1 ° 


< 0 . 1 ° 


<10ft 


<1 0ft 


<1 .Okts 


<2ft/min 


<1.0kts 


<1.0kts 


<1.0kts 


<1.0kts 


<1.0kts 


<1.0kts 


<1.0kts 


<0.1nm <0.2nm 
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>lHz 



>lHz 

<0.1 nm 

<0.2nm 

>lHz 

<1% 

<2% 

>lHz 

<1% 

<2% 

>lHz 



>5Hz 

<0.01 G's 

<0.02G's 

>5Hz 



>5Hz 



>5Hz 



>5HZ 

<0.01 dots 

<0.1 dots 

>5Hz 



>5HZ 

<0.01 dots 

<0.1 dots 

>5Hz 



>5Hz 

<0.001 

<0.1 

>lHz 

<1° 

<2° 

>lHz 

<.5 kts 

<1 .Okts 

>30Hz 

<0.5° 

<0.1° 

>lHz 

<.05° error 

<.r 


at lnm 

at lnm 


>30Hz 

>30Hz 

>30Hz 

>30Hz 


<.05° 
<.05° 
<.05° 
< 5ft 


<. 1 ° 
<. 1 ° 
<. 1 ° 
< 10fl 
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Aircraft Longitude, Decimal Degs 
(WGS-84) 


Aircraft GPS altitude above Mean Sea 
Level, ft (WGS-84) 


Aircraft altitude (Geoid Ref), ft 


Geometric Altitude 


Terrain Database Integrity (DIME) 


Terrain Database RMS 


< 5ft < 10ft 


<5 ft <10ft 



utopilot Inputs 


Autopilot Speed Mode 


Autopilot LNAV Mode 


Autopilot VNAV Mode 


Decision Height Value (Minimum 
Decent Altitude), ft 


Decision Height Indicator When 
Reached 


Selected Altitude, ft 


Selected Course/Track 


Selected Heading, Degs 


Selected Indicated Air Speed, kts 


Selected Vertical Speed, ft/min 


Other Systems 


GPWS warning values 


UTC Time, second past GMT midnight 


Weight On Wheels 


Post Flight Data Analysis 


>10Hz 

>5Hz 

>10Hz 

>5Hz 

>10Hz 

>5Hz 

>10Hz 

>5Hz 

>10Hz 

>5Hz 

>10Hz 

>5 Hz 

>10Hz 

>5Hz 

>10Hz 

>5Hz 

>10Hz 

>5Hz 

>10Hz 

>5Hz 




Local Pallet Event Marker Button 

>10Hz 

>5HZ 

Pilot's Longitudinal input 

>10Hz 

>5 HZ 

Pilot's Lateral Input 

>10Hz 

>5 HZ 


<.l%max <.5%max 


<.l%max <.5%max 
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Pilot's Left Throttle Input 

>10Hz 

>5 HZ 

<.l%max 

<.5%max 

Pilot's Right Throttle Input 

>10Hz 

>5 HZ 

<.l%max 

<.5%max 

Pilot's Wheel/Columns push-button 
selection input 

>10Hz 

>5 HZ 



Pitch Angle Rate, Deg/sec 

>10Hz 

>5 HZ 

<0.01 

<0.1 

Roll Angle Rate, Deg/sec 

>10Hz 

>5HZ 

<0.01 

<0.1 

SVS Mode Command 

>10Hz 

>5 HZ 

<0.01 

<0.1 


Table 4.3. SCRAMNet Requirements for RIPS 


Aircraft parameters 



EDCPstateS V SRD 

int 

25 Hz 

EDCPstateSVAD 

int 

25 Hz 

UTC_time 

float 

25 Hz 

OpMode 

short 

25 Hz 

RunNum 

short 

25 Hz 

LJat 

double 

25 Hz 

L_long 

double 

25 Hz 

L_alt 

float 

25 Hz 

WJat 

double 

25 Hz 

W_long 

double 

25 Hz 

W_alt 

float 

25 Hz 

BaroAlt 

float 

25 Hz 

RadarAlt 

float 

20 Hz 

Gspeed 

float 

10 Hz 

VertSpeed 

float 

25 Hz 

HeadingT 

float 

20 Hz 

HeadingM 

float 

20 Hz 

YawRate 

float 

25 Hz 

Pitch 

float 

25 Hz 

PitchRate 

float 

25 Hz 

Roll 

float 

25 Hz 



Pilot EDCP inputs to control SVS -RD 
Pilot EDCP inputs to control SV-A D 
GPS -derived time (msec) 


Operate mode (1 for flight, 0 for sim) 

Run number 

ownship latitude (deg), WGS 84, DGPS/INS 
ownship longitude (deg), WGS 84, DGPS/INS 
ownship altitude (feet MSL), DPGS/INS 
WAAS/INS latitude (deg) 

WAAS/INS longitude (deg) 

WAAS/INS altitude (feet MSL) 

Barometric altitude (feet MSL) 

Radar altitude (feet AGL) 

Ground speed (knots) 

Vertical speed (ft/min) 

Heading (deg true) 

Heading (deg magnetic) 

Yaw change rate (deg/sec) 

Pitch angle (deg) 

Pitch change rate (deg/sec) 

Roll angle (deg) 
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Roll Rate 

float 

25 Hz 

Roll change rate (deg/sec) 

TrackAngT 

float 

20 Hz 

Track angle (deg true) 

TrackAngM 

float 

20 Hz 

Track angle (deg magnetic) 

LonAccel 

float 

25 Hz 

Longitudinal accel. (G’s) 

LatAccel 

float 

25 Hz 

Latitudinal accel. (G’s) 

VertAccel 

float 

25 Hz 

Vertical accel. (G’s) 

AlongTrkAccel 

float 

25 Hz 

Along track accel. (‘G’s) 

CrossTrkAccel 

float 

25 Hz 

Cross track accel. (G’s) 

RightEngEPR 

float 

5 Hz 

Right engine EPR (no units) 

LeftEngEPR 

float 

5 Hz 

Left engine EPR (no units) 

TrueAirSpd 

float 

8 Hz 

True air speed (knots) 

CalAirSpd 

float 

8 Hz 

Calibrated air speed (knots) 

WindSpd 

short 

10 Hz 

Wind speed (knots) 

WindDir 

short 

10 Hz 

Wind direction (deg) 

Total AirTemp 

short 

2 Hz 

Total air temperature (deg C) 

ThrottlePos 

short 

25 Hz 

Throttle position (deg) (negative sign - reverse thrust) 

RudderPos 

short 

25 Hz 

Rudder position (deg) 

ElevatorPos 

short 

25 Hz 

Elevator position (deg) 

Air_Ground 

short 

25 Hz 

Air-ground state (1/0; 1 = main gear on ground) 

NoseWhlSqt 

short 

25 Hz 

Nosewheel squat (1/0; 1 - nose wheel on ground) 

ACWeight 

float 

1 Hz 

Aircraft weight (lbs) 

PitchFltCmd 

float 

25 Hz 

Flight Director pitch angle (deg) 

RollFltCmd 

float 

25 Hz 

Flight Director roll angle (deg) 

FltPathAng 

float 

20 Hz 

Flight path angle (deg) 

FltPathAccel 

float 

25 Hz 

Flight path accel. (G’s) 

ILSfrequency 

float 

5 Hz 

ILS frequency (kHz) 

ILSlocDev 

float 

16 Hz 

ILS localizer deviation (DDM) 

GlideSlopeDev 

float 

16 Hz 

ILS glideslope deviation (DDM) 

ILSCapFIag 

short 

16 Hz 

ILS capture flag (1/0; 1 = ILS frequency captured) 

Go Around 

short 

25 Hz 

Go -around flag (1/0; 1 = Go Around operative) 

GPSstatus 

short 

1 Hz 

GPS status (0-3; 0 = good, 1 = no differential 
corrections received but the smoothed solution is still 
good, 2 = smoothed solution bad but corrections now 
arriving, 3 = no corrections and smoothed solution is 
bad) 

W_GPSstatus 

short 

1 Hz 

WAAS status (0-3; 0 = good, 1 = no differential 
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EPRmode 


AutoThrotEng 


Sel_rwy 


FMSJVref 


Sel_speed 


Uplinked data 


Radarid[5] 


Radarfn[5] 


Radarcat[5] 


corrections received but the smoothed solution is still 
good, 2 = smoothed solution bad but corrections now 
arriving, 3 = no corrections and smoothed solution is 
bad) 


EPR Mode Annunciation (1 = operable) 


Autothrottle engaged (1 - engaged) 


Arr/Dep rwy selected via CDU 


Hz FMC calculated Vref 


Hz Pilot selected speed (MCP) 




Radarlat[5] 

float 

Radarlon[5] 

float 

Radaralt[5] 

short 

Radarspd[5] 

short 

Radarhdg[5] 

short 

Radamuc[5] 

short 

Radartime[5] 

float 

ADSBid[5] 

int 

ADSBfii[5] 

string 

ADSBcat[5] 

short 


1 Hz ID of object in scan 


1 Hz Flight# of object in scan 


1 Hz Category of object in scan 


Latitude of object in scan (deg) 


Longitude of object in scan (deg) 


Altitude of object in scan (feet) 


Speed of object in scan (knots) 


Heading of object in scan (deg) 


Navigation uncertainty of object in scan 


Time of traffic acquisition in msec GMT 


ID of ADS-B aircraft 


Flight# of ADS-B aircraft 


Category of ADS-B aircraft 


ADSBlat[5] 

float 

ADSBlon[5] 

float 

ADSBalt[5] 

short 

ADSBspd[5] 

short 

ADSBhdg[5] 

short 

ADSBnuc[5] 

short 

ADSBtime[5] 

float 

TgtScanCnt 

short 

NumTargets 

short 

MsgNum 

short 


Latitude of ADS-B aircraft (deg) 


Longitude of ADS-B aircraft (deg) 


Altitude of ADS-B aircraft (feet) 


Speed of ADS-B aircraft (knots) 


Heading of ADS-B aircraft (deg) 


Navigation uncertainty of ADS-B aircraft 


Time of traffic acquisition in msec GMT 


Scan counter 


# of targets in current scan (Radar object block only) 


Incoming ATC msg counter 
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MsgType 


Message 


The next 6 variables are 
provided by the research 
software 



Incoming ATC message type 


Incoming ATC message text 



AirportTemp 

float 

1 Hz 

Airport temperature (degrees of Celsius) 

AirportPressure 

float 

1 Hz 

Airport pressure - inches of Hg 

RwyWindSpd 

short 

1 Hz 

Runway Wind Speed (knots) 

RwyWindDir 

short 

1 Hz 

Runway Wind Direction (deg) 

RwyCond 

short 

1 Hz 

Runway Condition (0-dry, 1-wet) 

UATstatus 

short 

1 Hz 1 

UAT link status (0/1; 1 = corrupted) 



RIPS downlink data 
(provided by research 
software): 


ATCMsgNum 


ATCMsgID 


Taxi way 


RSMalert[2] 


RSMid[2] 


RSMsecs[2] 


RSMdist[2] 


RIAASalert[2] 


RIAASid[2] 


RIAASsecs[2] 


RIAASdist[2] 


RIAASrwy 


RIPS output data 
(provided by research 
software) 


SelExit 


AccelCmd 


rotoRWY_x 


rotoRWY_y 


IncursionAudio 


# of message responding to 


Type of ATC response 


Location of exit 


Incursion alert state (RSM) 


ID of incurring traffic (RSM) 


Seconds to collision (RSM) 


Distance in feet to collision (RSM) 


Incursion alert type (RIAAS) 


ID of incurring traffic (RIAAS) 


Seconds to collision (RIAAS) 


Distance in feet to collision (RIAAS) 


Runway of incurring traffic 



10 Hz 


25 Hz 


25 Hz 


25 Hz 


5 Hz 


Selected exit 


Commanded acceleration (ft/sec2) 


Runway x coordinate (ft.) 


Runway y coordinate (ft.) 


Aural message selection (0=none, l=”Runway Traffic, 
Runway Traffic”, 2=”Runway Conflict, Runway 
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AdvisoryAudio 


short 


5 Hz 


Aural message selection (0=none,l=”Off Route, Off 
Route”, 2=”Crossing Hold, Crosshg Hold”) 


short 1 Hz 

short 1 Hz 

Note: * indicates update on receipt 

Table 4.4. Required ARINC 429 DIME data parameters 




(♦Note: One channel of IRU measurements is acceptable if receiving all three is not practical.) 


Incursion monitoring source 
LAHSO position selected 


IncursionAlg 

LAHSOpos 


Part I- Requirements 
Page 45 



















































Table 4.5. Required ARINC 429 SV Sensors 



Source 


Fwd Norm Accel 

DAS 

IRU 

Fwd Lat Accel 

DAS 

IRU 

Fwd Lon Accel 

DAS 

IRU 

CG Norm Accel 

DAS 

IRU 

CG Lat Accel 

DAS 

IRU 

CG Lon Accel 

DAS 

IRU 

Aft Norm Accei 

DAS 

IRU 

Aft Lat Accel 

DAS 

IRU 

Aft Lon Accel 

DAS 

IRU 

GPS Blended Altitude 

Hybrid 

GNSS 

GPS Blended Lat Coarse 

Hybrid 

GNSS 

GPS Blended Lat Fine 

Hybrid 

GNSS 

GPS Blended Lon Coarse 

Hybrid 

GNSS 

GPS Blended Lon Fine 

Hybrid 

GNSS 

GPS Time Coarse 

Hybrid 

GNSS 

GPS Time Fine 

Hybrid 

GNSS 

Status Word #1 

Hybrid 

NEW 

Track (True) 

IRU 

IRU 

Magnetic Heading 

IRU 

IRU 

Heading (True) 

IRU 

IRU 

True Airspeed 

ADC 

ADC 

Baro Altitude (29.92) 

ADC 

ADC 

Baro Altitude 

ADC 

ADC 

Alpha 

DAS 

ADC 

Beta 

DAS 

ADC 


Table 4.6. Required ARINC 429 BAE data parameters 



361 

Inertial Altitude 

131,072 ft 

feet 

20 

0.125 


1 32 Hz 

312 

Ground Speed 

4096 kts 

knots 

15 

0.125 


32 Hz 

324 

Aircraft Pitch Angle 

+/- 180 deg 

degrees 

15 

0.005493 

up 

64 Hz 
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fp 

fflf 

'H 

i 

| 5 

i* H: * 

UhmmMf 

325 

Aircraft Roll Angle 


degrees 

15 



64 Hz 

313 

True Track Angle 

+/- 180 deg 

degrees 

15 


CW from 
True N 

■ 

314 

True Heading 

+/- 180 deg 

degrees 

15 

0.005493 

CW from 
TrueN 


322 

Flight Path Angle 

+/- 180 deg 

degrees 

15 

0.005493 

up 

32 Hz 

326 

Body Pitch Rate 

+/- 128 
deg/s 

deg/sec 

15 

0.003906 

up 

64 Hz 

327 

Body Roll Rate 

+/- 128 
deg/s 

deg/sec 

15 


right wing dn 

64 Hz 

330 

Body Yaw Rate 

+/- 128 
deg/s 

deg/sec 

15 


nose right 

64 Hz 


Vertical 

Acceleration 

+/- 4 g 

g’s 

15 

0.000122 

up 

64 Hz 

365 

Inertial vert Speed 



15 

1 

up 

32 Hz 

366 

N-S Velocity 

+/- 4096 kts 

knots 

15 

0.125 

north 

16 Hz 

367 

E-W Velocity 

+/- 4096 kts 

knots 

15 

0.125 

east 

16 Hz 


Radar Altitude 








GPS time (GMT) 








Note: a) Does not include the sign bit 

b) All Data is coded as Binary data except for Label 125 (System Time) 

c) If Radar altitude is not available from the ARINC 429 channel, then provide radar altitude 
from the radar altimeter (analog option). 

4.4.2 Recording 

4-79. The Data Processing and Display System (DPDS) shall provide display of 
researcher-selected variables and plots during test runs. This data shall also be 
provided upon request to the researcher at the completion of daily runs for post- flight 
analysis. 

Data Acquisition System (DAS) requirements will be provided under separate cover. 

4-80. In addition, DAS recording shall include all variables listed in Section 4.4.1, 
recorded at SCRAMNet refresh rates. 

4-81. Additional variables that shall be recorded are: 

• Corrected GPS PVT (Position, Velocity, and Time) data at 1 Hz. 

• Uncorrected GPS PVT data at 1 Hz. 

• WAAS GPS PVT data at 1 Hz. 

• INS latitude, longitude & altitude at 25 Hz. 
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PVT data is provided by GPS receivers and includes: 

-Latitude/longitude (WGS-84 degrees), altitude (MSL meters) 

-East, north, up coordinates in meters 

-East, north, up velocities in meters/second 

-HDOP, VDOP, and satellites in view 

-GPS time to 1 second 

4.4.3 Telemetry 

Not applicable. 

4.4.4 Uplink/downlink 

Not Applicable. 

4.5 Display Requirements 

4.5.1 Types/number 

Researcher display requirements at the pallets have been provided in pallet hardware 
requirements. 

4-82. In addition, the SVS-RD PFD and SVS-RD ND displays, identified under 
Sections 4.1.2, 4.1.3, and 4.1.4, shall be reproduced for display in the TTA utilizing 
the fiber optic connections. 


4.5.2 Location 

4-83. The TTA-Research Displays shall be mounted as high as possible on the pallet to 
facilitate viewing by all TTA occupants, consistent with pallet tipping moment 
limitations and without requiring significant modifications to the existing pallet 
mechanical structure. 

4.6 Communications Requirements 

4.6.1 Intercom 

4-84. Crewmembers shall be able to communicate from any seat position with (1) each 
other and (2) the flight deck. 

4-85. The RIPS and SVDC audible alert enunciations from the VRS shall be provided 
for the pilots in the flight deck and researchers to hear and for recording. This may be 
accomplished using the intercom system. 

4-86. Audio of the EP’s comments shall be routed to the 2U computer in the NASA 
pallet for recording. 

4-87. Audio input and output from the VRS shall be provided through the intercom 
system. 
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4.6.2 Radio 

No additional requirements. 

4.6.3 Recording 

4-88. Intercom audio shall be recordable on all video tapes. 

4-89. The audio outputs of the VRS and the NASA PC driving the Navigation Display 
shall be recordable on all video tapes. 

4.7 Video Requirements 

4.7.1 Inputs 

4.7.2 Recording 

4-90. All video recordings shall be time stamped with GPS-derived time to the second. 

The basic recording list will be specified in the InSITE Plan of Test. No more than 8 
sources will need to be recorded (excluding the SV Sensors recorders) during any one 
flight but the sources to be recorded may change between flights. 

4-91. The HUD Camera video recording in Table 4.7 shall be a direct recording of the 
HUD image, including the HUD raster and stroke imagery, and outside scene through 
the HUD. The recording shall not exhibit “rolling” of the raster and stroke imagery. 


Table 4.7. Video Requirement List. 



1 

R-C/BAE HUD 

ZxlO in R-C/BAE pallet (drives HUD) 

2 

R-C/BAE PFD 

ZxlO in R-C/BAE pallet (drives PFD) 

3 

R-C/BAE ND 

ZxlO in R-C/BAE pallet (drives ND) 

4 

NASA HUD 

ZxlO in NASA pallet (drives HUD) 

5 

NASA PFD 

ZxlO in NASA pallet (drives PFD) 

6 

NASAND 

ZxlO in NASA pallet (drives ND) 

■ 

Forward Camera View 

View from the camera mounted on the HUD combiner 
support structure 

8 

HUD Camera 

Miniature camera mounted in the HUD Eye Box for 
recording the HUD and external scene view 

9 

Forward Flight Deck Camera 

Fisheye view of the cockpit 

10 

Video mixer output from 2U 
computer (FLIR + symbology) 

2U computer in R-C/BAE pallet 

11 

BAE Image Processing Computer 
Output 

Fused FLIR and MMW Radar 

12 

Tail Camera 

Camera image from ARIES tail camera 

13 

EMM from ONYX 

RIPS EMM produced on ONYX 
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4 ' A MM. 


Video mixed PFD and ND 



Video mix of NASA PFD and ND 


Note: The required format for all Video Recording is SVHS. 

4.7.3 Distribution 

4-92. The video sources listed in Table 4.7 shall be distributed to TTA and other pallets. 


4-93. In TTA, the sources shall be selectable on both flat panel display and video 
monitors. The fiber optic Lightwave connections to both flat panel displays shall be 
selectable to provide the highest resolution possible for reproducing the PFD and ND. 


4.7.4 Uplink/downlink 

Not applicable. 
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5. SOFTWARE REQUIREMENTS 


5.1 Researcher-Provided Software 

5.1.1 Systems/subsystems 

The researcher-provided software is listed in Table 5.1. High-level descriptions of 
the software are included in this section for the reader’s reference. 

SVDC Software 

The SVDC software is designed to generate HUD and head-down display (HDD) 

SVS concepts. See Figure 5.1 . Two types of terrain texturing are employed on the 
HUD and HDDs: photo-realistic texturing and elevation-based color-coded texturing 
(also referred to as generic texturing). The SVS HDD concepts include terrain 
information on the PFD and ND with a pilot- selectable field of view (FOV). The 
FOV on the HUD is at unity minification, as it is a conformal display. Traffic 
information is also presented on the HUD, PFD, and ND when it meets certain 
display criteria. The RIPS displays (HUD and EMM) have been integrated with the 
SVDC display concepts and are rendered by the SVDC software. (A second EMM 
display is generated by the SGI- Onyx. See RIPS software description.) 

In addition to the SVS concepts, the SVDC software renders a conventional, size D, 
PFD and ND for use as a baseline condition. Terrain Awareness and Warning 
System (TAWS) information, cockpit display of traffic information (CDTI), and a 
vertical situation display are displayed on the ND for this baseline condition. SVAD 
FLIR overlay symbology, when used, is generated by the 2U rack computer on the R- 
C/BAE pallet. 


Part I- Requirements 
Page 5 1 




E 


Figure 5.1. SVDC Software Graphics Architecture 
RIPS Software 

The RIPS software is designed to present airport surface situational awareness and 
alerting to the pilot. A HUD is generated to provide improved position awareness 
during final approach, landing, roll out, turn off, and taxi. An EMM shows the airport 
layout graphically along with the current position of the ownship, current positions of 
other traffic, and ATC instructions. Runway incursion, route deviation, and crossing 
hold alerts are also generated and displayed to the flight crew. 

Runway incursion alerts are generated by two different onboard incursion detection 
algorithms. The Runway Safety Monitor (RSM) was developed by Lockheed Martin. 
The Runway Incursion Advisory and Alerting System (RIAAS) was developed under 
a cooperative agreement with Rannoch Corporation. 

The RIPS software will be provided by the research team. The RIPS graphics (both 
EMM and HUD) will be hosted on the SVDC PCs. The incursion alerting 
algorithms, control programs, and a second EMM will be hosted on the Onyx 
computer (see figure 5.2). 
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SCRAMNet Memory 


T 






Figure 5.2. RIPS Software Architecture 


DIME Software 

The DIME software is designed to detect significant disagreements between the 
stored terrain data and terrain profiles that are being sensed in real-time by 
ranging sensors on the aircraft. The ranging sensors used for this testing are the 
radar altimeters and the weather radar. The DIME software architecture is shown 
in Figure 5.3. The software components used to present information to 
researchers at the DIME pallet are not shown. 


Time (IRIG-B) 


IMU data (A-429) 


RA data (A-429) 
WxR data (A -45 3) 


WAAS/GPS data 
(A-429) 

Digital Terrain 
Elevation Data (DTED) 
(stored on DIME computer) 



SVDC Computer 
(TBD) 


Figure 5.3. DIME Software Architecture 
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The top four processes on the left in Figure 5.3 are responsible for interfacing 
with the data streaming in over the input ports from external devices. 
Specifically, once synchronized, position and attitude data coming from WAAS 
and the IRUs are used along with ranging measurements from the radar sensors, 
to create a synthesized terrain model. The parity handler process compares this 
synthesized terrain model with the model stored in the DTED file. Statistically 
significant differences between these two models are detected and alerts of 
integrity loss are then provided to the SVDC computer and ultimately to the pilot 
at the FDRS. 

Software contained within the architecture shown in Figure 5.3 will be provided 
and maintained by the DIME research team. As such, there are no SDB 
requirements for DIME software development. 

SV Sensors Software 

Based upon NASA research/results, Collins has decided to incorporate many of 
the SV Sensors-oriented applications into future WXR-2100 model radars. SV 
Sensors is providing 7 of these safety applications for use in the NASA SVS 
concept. Note, these applications are labeled on the lines joining the respective 
hardware devices in Figure 4.12. 

• Runway Confirmation (R/W) - The radar will locate the runway using a 
nominal ownship location provided by GPS, heading and other aircraft 
information from the inertial reference units (IRUs), and an airport database 
provided from the radar computers in Pallet 18. Results of this form of a 
Terrain Feature Extraction process are sent from the radar computers at 
Pallet 18 to the ARIES Onyx via an Ethernet link for distribution to SVDC 
on the SCRAMNet. 

• Air-to-Ground Runway Object Detection (A2G ROD) - Once the radar has 
confirmed the location of the runway, it will then switch to verifying the 
runway is clear of any large objects, including other aircraft, airport 
vehicles, or major debris. Once located, a track is established for each 
object. That track will be provided, via an Ethernet link, to the ARIES 
Onyx for use in the MTT process defined below. 

• Ground-to-Ground Object Detection (G2G OD) - Using an aircraft discrete 
(e.g., weight-on-wheels) and/or other aircraft-based parameters, the radar 
will switch into an ultra-short range configuration and continue to locate 
ground traffic/obstacles during taxi operation. Once located, a track is 
established for each object. That track will be provided, via an Ethernet 
link, to the ARIES Onyx for use in the MTT process defined bebw. 

• Non-Cooperative Aircraft Tracking (NCAT) - The radar will output track 
information on all air traffic within ~6NM and angularly within the field-of- 
view of the radar. Once located, a track is established for each object. That 
track will be provided, via an Ethernet link, to the ARIES Onyx for use in 
the MTT process defined below. 
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• Multi-Target Tracking (MTT) - a software module which will reside in the 
B-757 Onyx and which will blend TCAS, ADS-B, and radar-based object 
detections. SRB researchers developed this capability during the HSR 
Program and flew this software module in the NASA Onyx computer that 
was installed on the USAF TIFS aircraft. Our intention is to provide SDB 
(Onyx personnel) the source code that was used on TIFS, written 
documentation of the algorithms used, and then work with them to generate 
the MTT module for ARIES. 

• Terrain Feature Extraction (TFE) - The radar will generate a map of the 
terrain in front of the aircraft and will provide this measurement to the 
DIME computers via the Isolation box at Pallet 18 using an ARINC 453 
connection. 

• Terrain Obstacles - The radar will detect and locate any terrain features 
(including man-made objects) with significant height (those that impinge 
upon flight altitudes). Results of this process are sent from the radar 
computers at Pallet 18 to the ARIES Onyx via an Ethernet link for 
distribution to SVDC on the SCRAMNet. 


Other SVS Sensors software to be provided by the research team will process 
FLIR imagery as shown in Figure 5.4. 



Figure 5.4. SV Sensors Software Architecture 


Rockwell-Collins Display Concepts Software 
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The Rockwell Collins SVIS display software is designed to generate integrated 
terrain, traffic, weather and pathway displays for the HUD, PFD, multi- function 
display (MFD) and SVAD displays. Display concepts will be presented for 
airborne and surface operations. 

The HUD display uses conventional symbology combined with wireframe terrain. 
Sensor integration where the wire- frame is presented with FLIR imagery will be 
utilized. SGS symbology will be utilized on the ground. 

The PFD is an ego-centric perspective display of terrain, traffic, weather and 
pathway information. This display will be integrated with RIPS, DIME and the x- 
band radar experiments. Guidance modes will be consistent with the ships Mode 
Control Panel (MCP). This display will transition to an exo-centric perspective 
display for ground operations. FLIR imagery may be used in this display. 

The MFD is a co-planar display of terrain, traffic, weather and flight path. It 
consists of a map view and a vertical profile view. On the ground, only the map 
view will be displayed. FLIR imagery may be used in this display. 

The SVAD display will be a repeater of the HUD camera video for most runs, if 
the capability to display HUD video on the SVAD is provided. It might also be 
used as a PFD to evaluate whole cockpit procedures. The display may also be 
used to evaluate sensor integration concepts, subject to display video source 
limitations. 

BAE Display Concepts Software 

BAE Systems shall provide software to support the required and intended 
operations to support their concepts. Descriptions shall be provided at a later 
date. They intend to use NASA software for their PFD and ND. 

5.1.2 Providers) 


Table 5.1. List of Researcher- provided Software and Providers 



[ i| ofSIiS? : ill ; Jg 

1 

SVDC 

ConITS/Trey Arthur 

ZxlO, 2U 

2 

DIME 

Ohio University/ 
Steve Young 

DIME computer 

3 

RIPS 

Lockheed, Rannoch/Denise Jones 

Onyx, ZxlO 

4 

SV Sensors 

RTI/ Steve Harrah 

WXR-2100, PCs 

5 

RCSVS 

Rockwell-Collins/Tim Etherington 

ZxlO, HGS4000 

6 

BAE SYS 

BAE Systems//Dave McKay 

ZxlO, Fusion processor, 2U 
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5.1 .3 Interfaces 


5-1. Software shall be provided to support the Hardware Interfaces specified in 
Sections 4.1 and 4.3. 

5.1.4 Platforms 

See Table 5.1. 

5.2 Common Software to Simulation and Flight (SDB- 
developed software) 

5.2.1 Mathematical Representation 

Not applicable. 

5.2.2 Computational Techniques Considerations 

5-2. SDB shall develop software to provide an accurate estimate of the 757 ARIES 
true altitude with respect to Mean Sea Level. The true altitude estimate shall be 
entitled “geometric altitude” and be provided on the SCRAMNet with a minimum 
update rate of 50 Hz. The estimator resolution shall be consistent with the resolution 
of the corrected barometric altitude. 

5-3. Ownship surface position determination performance shall be no less than was 
provided during the RIPS trials at DFW in 2000. The solution should include 
filtering the DGPS position with the INS position and providing this blended solution 
to the RIPS. Note: two GPS receivers shall be employed at WAL/RNO (AshTech 
and WAAS). The AshTech/INS solution shall be used for ownship position 
determination. A WAAS/INS solution shall be selectable as a backup. Also note that 
the parameter values for the blending filter during surface position determination may 
require different values from the values used for flight position determination. 

5-4. SDB shall implement the Multi-Target Tracking (MTT) module on ARIES 
ONYX computer. 

Note: MMT is a software module which will reside in the B-757 Onyx and which 
will blend TCAS, ADS-B, and radar-based object detections. Sensors Research 
Branch researchers developed this capability during the HSR Program and flew this 
software module in the NASA Onyx computer that was installed on the USAF TIFS 
aircraft. The SV Sensors Pi’s intention is to provide SDB (Onyx personnel) the 
source code that was used on TIFS, written documentation of the algorithms used, 
and then work with them to generate the MTT module for ARIES. 

5.2.3 Display specifications 

5-5. SDB may be tasked to develop stroke symbology sets for recording and 
implementation on the HGS4000 by Flight Dynamics Incorporated (FDI). 

5.2.4 Audio Specifications 

None identified. 
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5.2.5 Data-Link Specifications 

None identified. 

5.2.6 Interfaces 

5-6. The System Development Branch (SDB) shall provide a SCRAMNet Data 
Interface (see Section 4.4.1). 

5-7. The SCRAMNet Data interface shall meet the desired data update and resolution 
requirements, as defined in Section 4.4.1. If required resolution and update rate can’t 
be achieved, then discussions will be conducted to either accept the best possible data 
rate and resolution, or remove the data from the SCRAMNet data request list. 

5-8. The data interface shall provide the capability to read all data in a highly- reliable 
and robust manner. In addition, data read protection shall be provided. Required data 
variables, update rates, and resolution is provided in Section 4.4.1. Additionally, 
there is a potential use of the SCRAMNet data interface for when the SVDC display 
system is employed in the IFD for piloted simulation evaluations. 

5-9. A bi-directional communication path between the VRS to the SVS display 
computers shall be established. Outputs of the VRS shall be placed on SCRAMNet. 

Note: The communications method will be mutually agreed upon by the VRS 

developer and NASA but this interface is expected to be RS-232. Software shall be 
written to establish the bi-directional communications and hand-shaking, transmit 
voice recognition vocabularies, receive VRS recognitions, transmit VRS speech 
generation commands, and transmit push-to-talk and sample noise commands, if 
required. An Interface Control Document (ICD) will be delivered to describe the VRS 
interface and identify bi-directional communications requirements. 

5-10. SDB shall develop software to communicate with the HGS4000 computer. An 
ICD will be delivered to support this task. 

5-11. Simulated Air Traffic Control (ATC) instructions are to be input by a RIPS 
researcher from a laptop located onboard the research aircraft through a control 
program running on the Onyx. These ATC inputs shall be provided to the RIPS 
software on the ONYX with minimal latency (<1 sec). The controller workstation 
that has been used in previous RIPS studies will not be utilized. 

5.2.7 Data Recording 

None identified. 

5.2.8 Graphical User Interface (GUI) 

None identified. 

5.2.9 Operational Scenario 

None identified. 

5.2.10 Performance Requirements 

None identified. 
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5.2.11 Assumptions, constraints, and dependencies 

None identified. 

5.3 Other Software Requirements 

5-12. The capability shall exist to make necessary changes, including modifications, 
deliverable media, etc., to the research software while on deployment. 
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6. SIMULATION REQUIREMENTS 


6.1 Lab checkout simulation required 

In general, RSIL or FSIL will be used to perform functional checkout of the flight 
system (figure 4.1) using actual hardware wherever practical. 

6.1.1 NASA SVS 

6-1. Since the FSIL/RSIL facility is required to refine the synthetic vision flight 
systems to prepare for actual flight testing, access to the FSIL/RSIL facility shall be 
provided well prior to deployment. 

6.1.2 SVDC 

6-2. The FSIL or RSIL shall be used for set-up and integration of the SVS-RD, HUD, 
SVAD, and the SVS-PCs with the SCRAMNet ring. Aircraft state data shall be 
supplied to the SVS-PCs via SCRAMNet. Support shall be provided to procure 
required SCRAMNet cards to effectively interface with the FSIL/RSIL facility and 
ARIES systems. Specific parameters to be supplied to the SVS-PCs are listed in 
section 5. 

6-3. The ability to fly a B-757 simulation model via simple joystick while viewing the 
SVS-RD, SVAD and HUD shall be provided. Maneuvering the B-757 simulation 
model via autopilot is required. Provisions to simulate flying the B-757 in the WAL 
or RNO vicinity, such as initialization of aircraft longitudinal and lateral positioning, 
shall be provided. 

6-4. The SVS-RD, SVAD, and HUD experimental displays should be recorded on 
video for FSIL/RSIL integration and testing. Data parameters being sent to the SVS- 
PCs shall be recorded to assist debug and checkout efforts. 

6-5. Evaluations in the FSIL/RSIL environment shall be used to establish satisfactory 
performance of the HGS-4000 HUD system. Satisfactory performance is defined as 
the ability to draw and control the brightness and contrast of flight guidance 
symbology and raster imagery, provided by the SVDC computers and FLIR cameras, 
on the HUD combiner glass. FDI stroke modes provided by the HGS-4000 computer 
shall also be evaluated. 

6.1.3 RIPS 

6-6. Display software developed and tested in the RSIL/FSIL shall be transferred to 
the IFD simulator environment and be tested while driving the actual flight deck 
displays (SVS-RD, SVAD, and HUD). Note: SVAD implementation in the IFD may 
deviate from the aircraft mechanical installation as required to enable implementation 
within resource and schedule constraints. Note: In RSIL/FSIL, the HUD can be 
mounted on a test rig. 

6-7. Flight hardware and software that is to be used to enable pilot control of the 
displays shall be integrated and tested for acceptable performance. 
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6-8. The Experimental Display Control Panel (EDCP) shall be used to accept pilots 
inputs directed to the EMM and the HUD. 

6-9. Flight hardware and software that is to be used for data link applications shall be 
integrated and tested for acceptable performance. Data link applications include: 
ADS-B and DGPS corrections. Software shall be developed to emulate interfaces to 
the data link hardware during RSIL/FSIL testing. Note: In lieu of RSIL/FSIL testing, 
the data links may be tested directly onboard the ARIES with ground-based 
equipment. 

6.1.4 DIME 

6-10. The FSIL/RSIL facility shall be used to demonstrate satisfactory performance of 
all interfaces shown on Figure 4.13. Satisfactory performance will be determined by 
the DIME Lead Researchers. 

6.1.5 SV Sensors 

The FSIL/RSIL facility is not required. 

6.2 Piloted SDB simulation support 

6.2.1 Introduction 

Under NASA’s Aviation Safety Program, flight testing of Synthetic Vision Systems 
will be conducted in the vicinity of WAL and RNO airports using the NASA Langley 
Research Center ARIES 757 aircraft. In preparation for this flight test, significant 
engineering development and checkout of the display concepts (hardware and 
software) in ground simulation is necessary. Several components of this ground 
simulation work are ideally suited for the IFD simulator. 

The purpose of the IFD simulations is to develop and evaluate key hardware and 
software components and operational procedures, as well as provide familiarization 
and training for the flight crew, including guest pilots, prior to the WAL/RNO 757 
deployment, thus, minimizing on-aircraft checkout. 

6.2.2 Project Scope 

Proposed Schedule: To be determined but tentatively starting approximately 3 

months prior to local area flight checkout, continuing through Reno flight 
deployment. It is anticipated that approximately 36 hours will be required for 
engineering development of systems concepts and checkout, followed by 
approximately 84 hours of pre-flight piloted test time. 

Ground simulation evaluations will be conducted by on-site NASA/Langley pilots, 
other test pilots and the planned WAL/RNO subject pilots. A formal plan of test for 
the IFD simulations will not be written as these sessions will be for pilot training and 
familiarization. However, pilot usability data may be gathered. A pilot briefing 
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guide will be provided by the InSITE researchers and used to brief the subject pilots 
both before the ground simulations and flight evaluations. 

6.2.3 Hardware Requirements 

6-11. Maximum commonality between the proposed InSITE flight test configuration 
and the IFD should be provided. Any modifications, alterations, or deviations from 
these requirements shall be mutually agreed upon. 


Key requirements are identified in this document to emphasize critical components or 
features. 

6-12. The IFD shall be used in the fixed-base mode only. 

6.2.3. 1 Key Modifications Needed to Existing Simulator 

6-13. The SVS-RD shall be installed on the left side of the flight deck. The installation 
should mimic the 757 ARIES configuration. This unit shall be one of the SVS-RD 
units from ARIES for this installation. 

6-14. The HGS-4000 HUD computer, HGS-4000 Mode Control Panel, HGS-4000 
Normal / Experimental Switch, and associated overhead projector unit shall be 
installed. Brightness, contrast, and declutter controls, as defined in this Flight Test 
Requirements document, shall be fabricated and installed to replicate those being 
fabricated and installed for ARIES. 

6-15. The SVAD should be installed in a method similar to that used for the ARIES, but 
may be installed in any mutually acceptable manner that can be accomplished within 
resource and schedule constraints. 

6- 1 6. The VRS shall be installed and interfaced in the IFD cockpit similar to that used 
in the ARIES (Section 4.6.1). 

6- 1 7. The HUD shall be aligned with the outside visual scene. 

6-18. ZxlO PCs and associated peripherals will be provided and shall be installed and 
interfaced into the IFD facility and the IFD simulator. Power, video, SCRAMNet, 
and other user- interface and network communications (such as Ethernet) devices shall 
be provided for this purpose. These customer- supplied computers will generate the 
SYS Display concepts developed by NASA, Rockwell-Collins, and BAE Systems. 


6.2.3.2 Visual Scene and Displays 

6-19. A local area and RNO database, including terrain and airports, will be provided 
and shall be used to generate an out-the-window visual scene. 

6.2.3.3 Audio System 

6-20. RIPS and SVDC audible alert enunciations shall sound in the flight deck via 
intercom. 
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6.2.3. 4 Visual Recording 
No modifications are needed. 

6.2.3.5 Audio Recording 
No modifications are needed. 

6. 2.3. 6 Interfaces 

6-21. The RIPS research team shall have a computer interface to the IFD environment 
to control the experimental system. This interface must support x- windows. 

6-22. Remote keyboard, video and mouse interfaces between the IFD cockpit and the 
SVS-PCs shall be provided. 

6-23. Interface definitions are provided in Section 4.3 of this document. These 
requirements shall be used to ensure commonality with the INitial SVS Integrated 
Technology Evaluation. 

6.2.3. 7 Discussion of Controls, Displays, Equipment 

6-24. All IFD controls and displays shall otherwise provide faithful replication of 
ARIES 757 functionality, to the extent that the existing IFD baseline configuration 
does so. 

6-25. The EDCP shall be installed on the left side of the flight deck for pilot inputs to 
the RIPS. 

6.2.3.S Performance Requirements 

Performance requirements are To -Be- Determined (TBD). 

6.2.3. 9 Procurements Needed 

No procurements have been identified. 

6.2.3.10 Fabrications Needed 

6-26. Hardware requirements have been specified above. Any fabrications shall be the 
responsibility of SDB. 

6.2.3.11 Constraints or Limitations 

Non-obvious constraints or limitations have not been identified. 

6.2.3.12 Assumptions or Dependencies 

Numerous assumptions and extreme dependencies with the ARIES 757 WAL/RNO 
deployment, as noted above, are in place. 

6.2.4 Software Requirements 

6-27. Maximum commonality between the proposed InSITE flight test configuration 
and the IFD should be provided. Any modifications, alterations, or deviations from 
these requirements shall be mutually agreed upon. Key requirements are identified in 
this document to emphasize critical components or features. This section details 
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simulation software only and does not pertain to customer- supplied software resident 
on the ZxlO PCs. 

6.2.4.1 Mathematical Representation 

6-28. A Boeing 757 aircraft simulation model, representative of the NASA ARIES, 
shall be provided. This model shall include the Flight Management System (FMS) 
with the published routes to WAL or RNO (i.e., the FMS approaches, departures, and 
missed approaches) available to be loaded as the default. Representative ARIES 
Boeing 757 FMS and pilot-FMS interface controls simulation including autoflight 
systems shall be provided. Known restrictions, limitations, or assumptions of these 
models shall be provided prior to the start of IFD simulations. 

6-29. Current WAL and RNO area navigation databases shall be implemented in the 
Flight Management System (FMS). 

6.2.4.2 Computational Techniques Consideration 

6-30. The FMS and aircraft state parameters on SCRAMNet data list (Section 4.4.1) 
shall be replicated on the IFD SCRAMNet ring for access by the customer-supplied 
PCs. This replication shall include, as a minimum, the aircraft state parameter 
characteristics (such as sensor location and approximate signal conditioning) and 
update rate. 

No other special computational techniques have been identified. 

6.2.4.3 Display Specifications 

6-31. Selected traffic shall be displayed on the out-the- window scene to evaluate 
runway incursion alerting algorithms. Traffic patterns will be defined by the research 
team and will emulate scenarios that will be conducted during the flight test. 

6.2.4.4 Audio Specifications 
None identified. 

6.2. 4. 5 Data Link Specifications 

6-32. There shall be no data link in this simulation. 

6. 2.4.6 Interfaces 

6-33. Traffic data shall be provided to the RIPS in the format and at the rates listed in 
Table 4.3. Note, during the flight test, traffic data will be provided to the RIPS by the 
ADS-B receivers and onboard fused surveillance data (MTT, ADS-B, TCAS, and 
radar objects). 

6-34. Interface definitions shall mirror the Flight Test Requirements (Section 4.3) to the 
greatest extent possible and practical. 
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6.2. 4 . 7 Data Recording 

6-35. Data recording shall be provided for simulation checkout and trouble-shooting. 
Indigenous data recording capability will be provided in the customer-supplied PCs. 
No other data recording shall be necessary. 

6.2.4.8 Graphical User Interface 

No graphical user interface requirements have been identified for the IFD. 

6. 2.4. 9 Operational Scenario 

6-36. Airborne and ground-based operations shall be conducted in the (simulated) WAL 
and RNO local areas. The capability to start the simulation, trimmed, straight-and- 
level or on-ground, at pre-defined points within the WAL or RNO databases shall be 
provided. The initial conditions shall be provided prior to the start of the simulations. 

6.2.4.10 Performance Requirements 

No unique performance requirements have been identified. 

6.2.4.11 Assumptions, Constraints, and Dependencies. 

Numerous assumptions and extreme dependencies with the ARIES 757 WAL/RNO 
deployment, as noted above, are in place. 

6.2.5 Simulation Facility Validation 

Certification of the simulation will not be necessary. The following validation 
measures are defined. 

6.2. 5.1 System Validation/Certification 

6-37. The following simulation characteristics are of significance in this test and shall 
be evaluated during the validation process: 

• FMS Mode Select Operation and Mode Annunciation 

• FMS Auto- Flight Selection and Operation 

• FMS Flight Guidance Display Characteristics 

• WAL/RNO Out-The- Window Scene (Evans- Sutherland generated) 

Correlation to HUD- Displayed WAL/RNO Terrain Database (ZxlO PC- 
generated) 

• Control Column Force-Position Characteristics (static and dynamic) 

• Control Wheel Force- Position Characteristics (static and dynamic) 

• Aircraft Response to Pilot Control Inputs (All Axes) 

• Multi- Target Tracking algorithm (MTT) 

• HUD Brightness, Contrast, and Declutter Control 

• SCRAMNet Data Correlation and Consistency to Aircraft-Measured 
Parameters 
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6.2.5.2 Validation Methods 

6-38. The aircraft and FMS subsystem models shall be quantitatively validated against 
the existing checkcases used in their respective developments. In the unlikely event 
that these FMS checkcases are not available, aircraft reference data or on-aircraft data 
shall be used to generate checkcase data. 

6-39. Known restrictions, limitations, or assumptions of these models, if any, shall be 
provided prior to the start of IFD simulation validation. 

6-40. Qualitative validation and simulation acceptance shall be conducted by pilot- in- 
the-loop simulation with SVS research personnel and NASA ARIES subject matter 
experts (i.e., test pilots). 

6.2. 5. 3 Acceptance Levels 

6-41. The acceptance levels used in the original quantitative simulation validation shall 
be reused. Acceptance levels for quantitative assessments are self-evident. 

6. 2. 5. 4 Validation Metrics 

6-42. The validation metrics used in the original quantitative simulation validation 
processes shall be reused. Qualitative validation metrics are TBD. 

6.2.5. 5 Validation Data 

6-43. Validation data, taken in the original quantitative simulation validation processes, 
if available, shall be reused. 

6.2. 5.6 Validation Set-Up 

6-44. Validation set-ups used in the original quantitative simulation validation 
processes, if available, shall be reused. Qualitative validations shall be performed 
from both static and dynamic maneuvers which will be defined at a later date. 

6.2.6 Experiment Definition 

The primary purpose of the IFD simulations is to develop and evaluate key hardware 
and software components, and operational requirements, as well as provide 
familiarization and training for the flight crew (including guest pilots) prior to the 
WAL/RNO 757 deployment. This process will minimize on-aircraft checkout and 
but it is not, per se, an experiment, although the simulations will use many of the 
same conditions and measures for verification and validation. 

6.2.6.1 Approaches and Procedures 

The broad objective is to evaluate and optimize flight deck procedures and planned 
flight maneuvers. Training and familiarization for both the safety and evaluation 
pilots will also be conducted. 

This part will begin with the conduct of planned flight maneuver segments and tasks. 
Upon successful completion, simulations may include parts of or entire planned flight 
profiles (once in the WAL or RNO local operating area). Data collection procedures 
and techniques may be used for training and critique. 


Part I- Requirements 
Page 66 



6. 2. 6. 2 Overall Matrix of Research Runs 

A simulation test matrix will not be established since the primary purpose of these 
simulations is checkout and training. However, a subset of the planned text matrix 
for the flight test will be used. 

6.2. 6.3 Simulator Sessions 

Simulator session definition has not been completed. For piloted simulation activity, 
three (3) hour blocks of simulation time should be planned using one subject pilot and 
test engineer. Two (2) blocks should be planned per day. Pre- simulation and post- 
simulation pilot briefing will be conducted around these simulation blocks. Note: 
This does not include simulation time required for checkout of equipment and 
interfaces prior to the start of piloted simulation sessions. 

6.2. 6.4 Output Information 

At this time, no output information is anticipated. 
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7. FLIGHT OPERATIONS REQUIREMENTS 


7.1 General Overview 

The following flight operations requirements are based on the research objectives 
given in Section 3.2.1, combined with the need to facilitate experimental system 
development. The details of the flight test will evolve as a natural consequence of 
simulation testing being performed for experimental systems development and 
research. The detail flight test plans will be published as part of the Flight Test and 
Safety Operations Report (FTOSR) and Plan-of-Test. 

The flight test will begin in the NASA/LaRC local area, primarily using the Wallops 
Flight Facility (FAA Identifier: WAL) as the testing location. It is anticipated that 
local area testing will launch and terminate at NASA/LaRC facilities located at 
Langley Air Force Base (LFI). Local area testing will focus on checkout and 
integration, followed by experimental evaluations/research focusing on RIPS, SVS- 
integration concepts, and CFIT-related scenarios and objectives. Both WAL and 
RNO databases and flight operation procedures will be used in the NASA/LaRC local 
area. Following successful NASA/LaRC local area testing, operations shall deploy to 
the Reno/Tahoe International, NV airport area (FAA Identifier: RNO) for flight test 
evaluations which shall emphasize DIME and SVS integration concepts. Only the 
RNO database will be used at RNO. While RNO and NASA/LaRC local area testing 
will emphasize certain technical and programmatic objectives, all SVS technical and 
programmatic areas will be represented and actively tested at each location. 
Showcase demonstration flights should occur at RNO, subject to resource and 
schedule constraints, and as agreed between AvSPO and AirSC management. 

Testing objectives and experimental scenarios will be developed prior to the start of 
the flight test to optimize flight test efficiency with consideration of the prioritized 
research objectives. 

7.2 Location 

7.2.1 Check-out Locations and Local Research Sites 

7-1. NASA/LaRC (located at Langley Air Force Base, FAA Identifier: LFI) shall 
be the primary base for check-out and local research operations. Check-out and 
local area research operations shall employ Newport News/Williamsburg (PHF), 
NASA Wallops (WAL), and Langley Air Force Base (LFI) airports. 

7-2. Experimental systems development shall enable any of these facilities to be 
employed. All planned WAL and RNO evaluation tasks, including approach and 
landing operations, through runway and taxi operations, shall be considered as 
viable options for initial planning. As flight test development progresses, 
downselection of operations to certain airports and runways may be possible due 
to facility and equipment restrictions. 
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7-3. Up-and-away air work in the NASA/LaRC local area shall also be expected 
for system checkout and development. 

Selection of facilities for a specific flight will be determined based on air traffic, 

weather, research objectives, or other logistical considerations during the 

development of the specific flight test maneuvers and flight cards. 

7-4. Pre-deployment of other appropriately equipped Langley Research Aircraft 
and Langley researchers and other support personnel to these local area facilities 
shall be provided, as necessary, to support testing objectives. 

7-5. Differential GPS correction shall be provided to ensure uninterrupted and 
simultaneous operation, including landing, roll-out, takeoff, and taxi testing, at 
each local airport. 

7-6. Coordination with local Air Traffic Control personnel shall be conducted to 
ensure smooth and efficient operations. 

7.2.2 Deployment sites 

7-7. Following successful completion of checkout and research objectives in the 
local NASA/LaRC area (i.e., WAL-testing), operations shall deploy for flight test 
evaluations at Reno, NV (RNO) that will emphasize DIME and SVS integration 
concepts in an operationally- realistic, terrain-challenged environment. 

7-8. Differential GPS correction shall be provided to ensure uninterrupted and 
simultaneous operation, including landing, roll-out, takeoff, and taxi testing, for 
RNO. 

7-9. Coordination with local Air Traffic Control personnel shall be conducted to 
ensure smooth and efficient operations. 

7.3 Participation by Langley Research Center Aircraft 

7-10. All test flights shall be conducted using the NASA Boeing 757 ARIES. The 
requirements for which are contained herein. 

7-11. The NASA Be-200 aircraft (or mutually- accepted replacement) shall be 
operated as an intruder aircraft in RIPS test scenarios, radar surveillance and 
detection scenarios (detection of dynamic object), and SV-cockpit display of 
traffic information (CDTI) scenarios. The Be-200 aircraft shall be available for 
both local area and RNO testing. The Be-200 may not be required on all flights 
but should be considered as such for planning purposes. Scheduling will be based 
on testing objectives and experimental scenarios (see Section 7.1). The Be-200 
shall be equipped with ADS-B with altitude reporting. The ADS-B data shall 
consist of the parameters listed in Table 4.3. UAT data link is preferred. 

7-12. During local area evaluations, participation by the NASA C-206 aircraft as an 
additional intruder aircraft is desired and should be made available as C-206 
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priorities dictate. No actions should be taken to preclude the use of the NASA C- 
206 during these local area research flights. If available, the G206 shall be 
equipped with ADS-B with altitude reporting. The ADS-B data shall consist of 
the parameters listed in Table 4.3. UAT data link is preferred. 

7.4 Participation by Non-Langley Research Center Aircraft 

During RNO evaluations, a Piper Cheyenne aircraft (PA-42), operated by Marinvent 
Corporation, might participate as an additional intruder aircraft. The flight test 
capabilities of the Marinvent Cheyenne are mailable at the Marinvent web site 
(www.marinvent.com) . Marinvent is under contract with Boeing/Jeppesen to support 
their synthetic vision efforts. Boeing/Jeppesen is a NASA/LaRC Cooperative 
Research Agreement partner in the Synthetic Vision Systems Project. During WAL 
evaluations, a Rockwell Collins Sabreliner-50 aircraft might participate as an 
additional intruder aircraft. The Sabreliner will transmit/receive ADS-B via 
1030/1090 data link. All joint flight operations involving non-NASA aircraft shall be 
approved by the LaRC ASRB, the LaRC Aviation Manager, and all involved LaRC 
research pilots. 

7.5 Participation by Ground Vehicles 

During local area evaluations, participation by a ground vehicle (e.g., a van) as an 
additional intruder will be used. Such participation shall be approved by the LaRC 
ASRB, the LaRC Aviation Manager, and all involved LaRC research pilots. 

Ground vehicles may be used to assist in the calibration of systems during checkout 
and integration testing. 

7.6 Meteorological Phenomena of Interest 

The desire of the InSITE team is to: 

a) maximize research flight time by developing operational margins and procedures 
which allow for flying in other than visual meteorological conditions, and 

b) conduct research flights in operationally-realistic weather conditions to fully 
develop and test the technologies being implemented for this flight test. 

It is not the desire of the team to alter the flight test schedule or deployment in an attempt 
to find specific weather conditions. 

7-13. Specific flight test maneuvers and operational scenarios, including risk 
mitigation strategies, methods, and procedures for safe and efficient flight testing, 
shall be mutually developed which allow research operations in the 
meteorological phenomena (detailed below) within the Boeing 757 flight 
envelope, subject to Airworthiness and Safety Review Board and LaRC 
management approvals. 


Prioritized Meteorological Conditions 
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1 . Day VMC (with and without simulated IMC) 

2. Night VMC 

3. IMC -VMC Transitions 

4. IMC - surface operations only 

7.7 Proposed Number of Flights and Frequency 

7-14. The flight test shall be composed of four phases. These phases should occur 
without significant delay between phases or aircraft reconfiguration to ensure that 
equipment calibration and integration integrity is maintained; otherwise, re- 
installation, re-calibration, and checkout may be necessary between phases. 

7-15. The first phase shall be for system checkout, integration checkout, and pre- 
research scenario development. This phase shall be conducted in the 
NASA/LaRC local area. This phase shall consist of no less than 1 5 flight hours, 
flown in no fewer than three sorties. This phase shall continue until acceptable 
performance is observed by the SVS Lead Researchers. The frequency of local 
check-out flights shall be adjusted to permit a reasonable “test- and- fix” 
operational scenario for data analysis, system debugging, and sortie/scenario 
development and planning. Any instrument check flights or build-up, risk- 
mitigation flight testing required as part of ARIES development or FTOSR- 
imposed stipulations shall be over and above this flight test estimate. 

7-16. The second phase shall consist of research flying in the local NASA/LaRC 
area. This phase shall consist of no less than 30 flight hours, flown in no fewer 
than seven sorties. Flights may be flown on consecutive days. However, some 
brief down time between sorties might be requested for data analysis, system 
debugging, sortie/scenario development and planning and accommodation of 
evaluation pilot travel schedules. 

7-17. The third phase shall consist of research flying on deployment to the 
Reno/Tahoe International Airport operating area. The first sortie conducted on 
the Reno/Tahoe International Airport deployment shall be used for local area 
checkout, familiarization, and pre- research sortie/scenario development and 
planning. Given successful completion of the systems checkout flight on 
deployment, the sortie frequency shall shift toward maximum operational use of 
ARIES. This phase shall consist of no less than 30 flight hours, flown in no fewer 
than seven sorties. Evaluation pilots (and designated VIPs/Observers) will be 
scheduled contiguously throughout this phase for maximum operational 
frequency. 

7-18. The fourth phase should consist of showcase demonstration flying for Very 
Important Persons (VIPs) on deployment at Reno/Tahoe International Airport. 
This phase may be eliminated due to resource and schedule constraints, per 
mutual agreement of AvSPO and AirSC management. If it occurs, it is 
anticipated that this phase should consist of one day to conduct at least one sortie 
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for rehearsal, followed by three (3) days of two (2) sorties per day with one sortie 
scheduled in the afternoon and one sortie in the evening/night. 


7.8 Planned Flight Test Envelope (Proposed Flight Test 
Maneuvers) 

7-19. All maneuvers shall be flown within the normal operational envelope of the 
Boeing 757 ARIES aircraft. Non-normal aircraft conditions (e.g., single engine 
departures) might be simulated to increase evaluation pilot workload and stress 
the evaluation pilot’s use of the synthetic visions systems concepts (subject to 
ASRB approval). 

Detailed flight test operations and test maneuvers will be developed in preparation for 
the flight test. These operations and maneuvers will be detailed in the FTOSR and 
Plan-of-Test, to be published prior to the start of flight test. 

Evaluation tasks will be mutually developed by tailoring existing FAA-approved 
approach and departure procedures. Tailoring will be applied to define procedures 
and constraints which aid in experimental data collection and subsequent data 
analysis. Further, the tailoring and evaluation maneuvers will take into account the 
weather and visibility conditions which exist for the evaluation since low/impaired 
visibility and flight in actual weather conditions are planned. 

The test will primarily emphasize approach and departure maneuvers and surface 
operations, including approved low visibility runway and taxiway operations. 

Proposed operations might include: 

• ILS, Visual, and non-precision approaches (including Localizer/Distance 
Measuring Equipment (LOC/DME) approaches) to full-stop, touch-and-go, or 
wave-off. 

• Take-off. 

• Taxi operations. 

• Departures and wave-offs using reduced throttle settings to simulate single 
engine climb gradients. 

• Autopilot Coupled Approaches, (using ship’s system signals) 

• Straight-and- level low altitude segments (<5000’ AGL, Clear below) 

Typically, experimental evaluations will dictate that the Evaluation Pilot is the pilot 
flying; however, scenarios and tasks might be developed where the EP observes a 
research display while sitting in seat 3 or 4 as the NASA Pilots assume the Pilot- Flying 
(PF) and the Pilot-Not-Flying (PNF) duties. 

7.9 General Test Procedures 

7-20. Multiple evaluation runs shall be flown on a given flight. 




Part I- Requirements 
Page 72 



7-21. Each evaluation run shall involve a planned flight profile/evaluation task with 
pre-planned and controlled experimental conditions, consisting of combinations 
of weather, actual or simulated outside visibility, SV systems concepts, simulated 
non-normal situations, and the presence or absence of intruder aircraft. 

7-22. Each evaluation shall be pre-briefed on the ground and set-up, with 
verification, before execution in-flight. 


Following each in-flight evaluation, flight to a pre-briefed altitude and operating area, 
under safety pilot control, may be executed to allow time to set-up for the next 
scenario and collect evaluation pilot comment and other data. Similar procedures 
may be used for surface operation evaluations. 

7-23. A mix of outside and NASA-LaRC evaluation pilots shall be used. Non- 
LaRC pilots shall meet evaluation pilot qualifications determined by the Pilots 
Office and approved by the Aviation Manager. 

7.10 Special Training Requirements 

7-24. Training and familiarization in the NASA/LaRC VISTAS-3 simulation 
facility or the IFD simulator shall be required by all participating evaluation 
pilots, including those both outside and within NASA-LaRC. 

7.11 System Validation Requirements 

7-25. Baseline systems verification and validation shall be performed in accordance 
with existing ARIES standards. 

7-26. In addition to standard systems verification, the following items are of special 
interest and shall be validated (exact methods: TBD). These are: 

1) Terrain Database Alignment and Aircraft Positional Accuracy: 

The terrain database and associated aircraft positional data shall be 
verified. This verification shall be conducted prior to the start of or during 
the local area checkout and also, during the checkout phase on the RNO 
deployment. Procedures for this process shall be developed no later than 2 
months prior to the start of aircraft integration testing. 

2) HUD alignment and Optical Performance: 

HUD alignment verification and validation procedures similar to that 
employed during the EGE deployment shall be conducted prior to the start 
of the flight tests as given by References 4 and 5. In addition, installed 
HUD performance, related to luminance, shall be tested following SAE 
ARP5287 (“Optical Measurement Procedures for Airborne Head-Up 
Display”) during aircraft integration testing. 
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3) FLIR pod alignment and image scaling: 

FLIR pod alignment and image scaling verification and validation 
procedures similar to that employed during the EGE deployment shall be 
conducted prior to the start of the flight tests. 

The special systems verification requirements, methods, and procedures will be 

mutually developed with completion of requirements, methods, and procedures no 

later than 2 months prior to the start of aircraft integration testing. 

7-27. Other special experimental interest or unique validation requirements may 
also arise. These requirements shall be submitted no later than 2 months prior to 
the start of flight test. Methods and procedures shall be mutually- developed and 
published prior to the start of aircraft integration testing. 

7.1 2 Flight Crew Staffing Requirements 

7.12.1 Support personnel from AirSC 

7-28. Standard support personnel to operate the Transport Research System shall be 
provided. 

7.12.2 Researchers & Observers 

Researchers will include personnel from NASA/LaRC, Rockwell-Collins, BAE 

Systems, Research Triangle Institute, Ohio University, University of Iowa, 

Marinvent, Jeppesen, Rannoch, Raytheon, and Boeing. 

7-29. The Technology Transfer Area (TTA) shall be made available whenever SVS 
flight-testing is in progress. Maximum seating possible in the TTA is requested, 
subject to the constraints of 7-32. 

7-30. During evaluation runs, at least one seat, either Seat #3 or #4 in the cockpit, 
shall be available for a researcher. If a NASA/LaRC pilot is serving as an 
evaluation pilot, either Seat #3 or #4 shall be available for a researcher and both 
Seats #3 and #4 are requested for researchers/observers. 

7-31. The seating requirements for researchers in the cabin area shall be as follows: 

1) NASA SVDC - Three seats in a single row at the NASA-SVDC pallet 
(identical to that of the SVS -EGE flight test) shall be provided. 

2) R-C / BAE - Three seats in a single row at the pallet (identical to that of 
the SVS-EGE flight test) shall be provided. Accommodations shall be 
provided in either the TTA or other unoccupied seats in the cabin area for 
the industry customers not currently occupying the pallet location. 

3) DIME - Two seats, side-by-side shall be provided with keyboard, 
monitor, and cursor control device interfacing with the DIME computer. 

4) RIPS -Two seats, side-by-side shall be provided with keyboard, monitor, 
and computer access to the SGI/Onyx computer (possibly remote). Also, 
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one seat, with keyboard, monitor, and computer access to the SGI/Onyx 
computer shall be provided at the SGI/Onyx operations pallet. 

5) SV Sensors - Three seats in a single row at the SV Sensors pallet 

(identical to that of the SVS-EGE flight test) shall be provided. The 

second row of three seats immediately behind the SV Sensors pallet 

should also be provided. 

7-32. Observers will be designated by a designated AvSP person in a similar 
manner to that employed during the SVS-EGE flight test. In general, the seating 
locations for observers shall be in the TTA area primarily, and secondarily, at the 
SVDC-1 (NASA pallet) and SVDC-2 (R-C/BAE pallet) pallets and Seats #3 and 
#4 in the cockpit. 


7.1 3 Photographic Requirements 

7-33. Photographic support shall include ground-based and in-cockpit 
documentation and public- relations style photography. 

7-34. Aerial photographic support shall be provided during NASA/LaRC local area 
operations and should be provided during RNO deployment operations if feasible. 

7.14Chase Requirements 

None. 

7.1 5 Ground Support Requirements (Equipment/Facilities) 

7.15.1 Meteorological support 

7-35. The reported runway visual range (RVR) at the test airport shall be recorded 
at 30 minute intervals when Instrument Meteorological Conditions prevail or are 
expected during the daily test period. To meet this requirement, an estimate of 
RVR shall be requested of airport personnel in such cases that no automated RVR 
measurement system is available at the test airport. 

7-36. Weather briefings shall be provided to support local and remote operations. 

7.15.2 Communications 

7-37. Communications to the differential GPS ground station operator shall be 
provided. Communications with a NASA-program liaison stationed at relevant 
local area Air Traffic Control (ATC) facilities should be provided since SVS-EGE 
experience showed that this interface was extremely beneficial. 
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7.15.3 Telemetry 

None. 

7.15.4 Tracking 

None. 

7.15.5 Data 

None. 

7.15.6 Other 


7-38. Equipment necessary to provide quick- look video and engineering unit data 
shall be provided as necessary to support operations of ARIES. 

7-39. During the deployment to RNO, a location shall be provided to accommodate 
equipment and researchers to conduct post flight data analysis and software 
modifications. 


7.16 Special System Pre-/Post-Flight Calibration 
Requirements 

Pre- flight and post- flight calibration methods for terrain database alignment/aircraft 
positional accuracy, HUD alignment/optical performance, and FLIR pod alignment 
and image scaling (Section 7.1 1), while on deployment might be required. 

Requirements for special pre- flight and post- flight calibration, if they arise, will be 
provided no later than 2 months prior to the start of flight integration. 
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9. APPENDICES 


9.1 Appendix A. List of Acronyms 


2U 

computer of thickness 3 and Vi inches 

ADS-B 

Automatic Dependent Surveillance Broadcast 

AGL 

Above Ground Level 

ALTM 

Airborne Laser Terrain Mapping 

ANP 

Actual Navigation Performance 

ATC 

Air Traffic Control 

AvSP 

Aviation Safety Program 

BAE 

BAE Systems 

CAB 

Commercial and Business Jet 

CDTI 

Cockpit Display of Traffic Information 

CFIT 

Controlled Flight Into Terrain 

DAS 

Data Acquisition System 

DEM 

Digital Elevation Model 

DFW 

FAA Identifier for Dallas/Fort Worth International Airport 

DGPS 

Differential Global Positioning System 

DIME 

Database Integrity Monitoring Equipment 

DPDS 

Data Processing and Display System 

EDCP 

Experimental Display Control Panel 

EGE 

FAA Identifier for Eagle/Vail County Regional Airport 

EMM 

Electronic Moving Map 

EP 

Evaluation Pilot 

ET 

Enabling Technologies 

EVS 

Enhanced Vision Systems 

! FDRS 

Flight Deck Research Station 

FLIR 

Forward-Looking Infra-Red 

FMS 

Flight Management System 

FSIL 

Flight System Integration Laboratory 

FTOSR 

Flight Test Operations and Safety Report 

GPS 

Global Positioning System 

GUI 

Graphical User Interface 

HDD 

Head- Down Display 

HGS 

Head-up Guidance Systems 

HUD 

Head-Up Display 

ICD 

Interface Control Document 

IFD 

Integration Flight Deck 

IMC 

Instrument Meteorological Conditions 

INS 

Inertial Navigation System 

IRU 

Inertial Reference Unit 

LCD 

Liquid Crystal Display 

LFI 

FAA Identifier for Langley Air Force Base 

; LOC/DME 

Localizer/Distance Measuring Equipment 

MCP 

Mode Control Panel 

| 
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MFD 

Multi-Function Display 

MMWR 

Millimeter-Wave Radar 

MSL 

Mean Sea Level 

MTT 

Multi- Target Tracking 

NCAT 

Non-Cooperative Aircraft Tracking 

NAV 

Navigation Display 

NavD 

Navigation Display 

ND 

Navigation Display 

PC 

Personal Computer 

PDU 

Pilot Display Unit 

PF 

Pilot Flying 

PFD 

Primary Flight Display 

PHF 

FAA Identifier for Newport News/Williamsburg International Airport 

PNF 

Pilot Not Flying 

R-C 

Rockwell Collins 

RIAAS 

Runway Incursion Advisory and Alerting System 

RIPS 

Runway Incursion Prevention System 

RNO 

FAA Identifier for Reno/Tahoe International Airport 

RNP 

Required Navigation Performance 

RSIL 

Research System Integration Laboratory 

RSM 

Runway Safety Monitor 

RVR 

Runway Visual Range 

SDB 

System Development Branch 

SGS 

Surface Guidance System 

SV 

Synthetic Vision 

SVAD 

Synthetic Vision Auxiliary Display 

SVDC 

Synthetic Vision Display Concepts 

SVIS 

Synthetic Vision Information System 

svs 

Synthetic Vision System 

SVS-RD 

Synthetic Vision System-Research Display 

SXGA 

Video format, 1280x1024 pixels 

TAWS 

Terrain Awareness and Warning System 

TBD 

To-Be- Determined 

TCAS 

Traffic Alert and Collision Avoidance System 

TFE 

Terrain Feature Extraction 

TTA 

Technology Transfer Area 

UAT 

Universal Access Transceiver 

VFR 

Visual Flight Rules 

VIP 

Very Important Person 

VMC 

Visual Meteorological Conditions 

VRS 

Voice Recognition System 

WAAS 

Wide Area Augmentation System 

WAL 

FAA Identifier for Wallops Flight Facility 

WIU 

Wire Interface Unit 

Wx 

Weather 

WxR 

Weather Radar 
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XGA 

ZxlO 


extended Graphics Architecture, 1024x768 pixel resolution 
Dual- Pentium computer by Intergraph 
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Part II 

Hardware Architecture for the Initial 
Synthetic Vision Systems Integrated 
Technology Evaluation Flight Test 
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This part of the document contains information pertaining to the complex, integrated 
hardware architecture that was realized to meet the requirements listed in Part I of this 
document. The system architecture was presented to a Critical Design Review Panel and 
approved for installation on the B- 75 7 Airborne Research Integrated Experimerts 
Systems (ARIES) airplane. This information includes a description of the equipment, 
block diagrams of the architecture, layouts of the workstations, and pictures of the actual 
installations. 

1. HARDWARE DESCRIPTION 

1.1 Head-Up Display (HUD) 

The HUD consists of a Rockwell Collins HGS-4000 computer located in the Electronics 
Equipment (EE) bay, and an overhead projector, combiner glass, HUD control panel, and 
raster control panel located in the flight deck of the airplane. 

1.2 SVS Head-Down Research Display (SVRD) 

The SVRD is a dual- glass display installed in front of the pilot’s main instrument panel in 
the flight deck. The display covers the pilot’s primary flight displays and is removable in 
ten seconds or less. 

1.3 Evaluation Pilot’s Auxiliary Display (EPAD) 

The EPAD is a portrait mode display located in the pilot’s left side console, and can 
display either computer generated images, composite video images, or super video 
images. 

1 .4 Jump Seat Auxiliary Display (JSAD) 

The JSAD is a landscape mode display mounted on the aft end of the center console. The 
JSAD is a repeater of the EPAD for viewing by the principal investigator during the 
flight. 

1.5 Voice Recognition System (VRS) 

The VRS is a speaker- independent recognition system and audio alerting system 
connected to the TRS for use by the research systems. It consists of a Push-To- Listen 
(PTL) button on the pilot’s control column, a headset interface unit located on the aft end 
pilot’s side console, and a computer located in the cabin of the airplane. 

1.6 Vision Restriction Device (VRD) 

The VRD is a piece of flame retardant material that obstructs the pilot’s vision when he is 
flying. It is designed to limit the evaluation pilot’s forward view while minimizing the 
obstruction to the safety pilot. The VRD is easily removed and has a flip-up portion that 
allows the pilot’s vision to be totally blocked or limited to 300 feet. 
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1 .7 Forward Looking Infrared (FLIR) camera pod 

The FLIR pod is located under the nose of the airplane and consists of two IR cameras 
and a visual camera. 

1 .8 Research Radar System 

The research radar system consists of a receiver/transmitter located in the forward EE bay 
and an antenna and pedestal located under the radome as well as support equipment 
located in the cabin. 

1 .9 BAE Millimeter wave Radar (mmWR) System 

The mmWR system consists of a receiver/transmitter located under the radome, an Image 
Fusion Processor located in the forward cargo bay, and some support equipment located 
in the cabin. Since the mmWR and the weather radar radiate at two different frequencies, 
a special radome was also installed. 

I.IOCabin equipment 

InSITE has two dedicated pallets consisting on 10 computers, numerous video 
distribution amplifiers and switches, two computer interface terminals, and eight displays 
to drive the displays in the cockpit. Another dedicated pallet, consisting of four 
computers, two computer interface terminals, two large screen displays, and radar 
isolation units, is used to interface with the FLIR and the research radar. In addition, the 
project has a three-processor computer and interface terminal to support DIME, and 
interfaces to provide high-resolution video in the TTA of the ARIES. 
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2. BLOCK DIAGRAMS AND LAYOUT DIAGRAMS 



Figure 2.1. Cabin Layout for B-757 ARIES 
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Figure 2.11. Radar Block Diagram 

















Figure 2.12. FLIR Block Diagram 
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Figure 2.16. Pallet 4-NASA SVDC Workstation Layout 
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Figure 2.17. Pallet 18-Radar/FLIR Workstation Layout 
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Figure 2.18. Pallet 12-DPDS/DIME Workstation Layout 
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Figure 3.3. 


Figure 3.4. 
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Figure 3.5. Radome Area Overview 



Figure 3.6. BAE Image Fusion Processor 
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Figure 3.7. 


Figure 3.8. 




Pallet 3-Industry SYS Concepts Workstation 


Pallet 4-NASA SVDC Workstation 
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Figure 3.9. Pallet 18-Radar/FLIR Workstation 


Figure 3.10. Pallet 12-DPDS/DIME Workstation 
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Figure 3.1 1. Pallet 15-TTA-l 


Figure 3.12. Pallet 1 6-TTA-2 
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4. ACRONYMS 


2U 

2 rack units 

ARIES 

Airborne Research Integrated Experiments Systems 

B## 

B number- number assigned to unit, similar to serial number 

BAE 

BAE Systems 

CCD 

Computer Control Device 

Conv 

Converter 

DAS 

Data Acquisition System 

DIME 

Database Integrity Monitoring Experiment 

DPDS 

Data Processing and Display System 

EE 

Electronic Equipment 

EMM 

Electronic Moving Map 

EP 

Evaluation Pilot 

EPAD 

Evaluation Pilot Auxiliary Display 

FLIR 

Forward Looking Infrared 

FMS 

Flight Management System 

GPS 

Global Positioning System 

GUI 

Graphical User Interface 

HUD 

Head-Up Display 

ICS 

Inter Communication System 

IFP 

Image Fusion Processor 

InSITE 

INitial SVS Integrated Test Evaluation 

IRP 1000 

Folsom Rotation Card 

IRU 

Inertial Reference Unit 

ISO 

Isolation Unit 

JSAD 

Jump Seat Auxiliary Display 

KGPS 

Kinematics (differential) GPS 

KVM 

Keyboard, Video, Mouse unit 

LWIR 

Long Wave Infrared 

mmWR 

millimeter Wave Radar 

NAV 

Navigation 

ND 

Navigation Display 

OHU 

Overhead Projector Unit 

PC 

Personal computer 

PFD 

Primary Flight Display 

PTL 

Push-To-Listen 

PIT 

Push-To-Talk 

PWR 

Power 

RA 

Radio Altimeters 

R-C 

Rockwell Collins 

RGBHV 

Red, Green, Blue, Horizontal, vertical 

Rx 

Receiver 

SP 

Safety Pilot 

SV 

Synthetic Vision 

SVDC 

Synthetic Vision Display Concepts 

SVRD 

Synthetic Vision Research Display 
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svs 

Synthetic Vision Systems 

sw 

Switch 

SWIR 

Short Wave Infrared 

TTA 

Technology Transfer Area 

Tx 

Transmitter 

VDA 

Video Distribution Amplifier 

VRD 

Vision Restriction Device 

VRS 

Voice Recognition System 

W/G 

Wave Guide 

WAAS 

Wide Area Augmentation System 

WGPS 

WAAS GPS 

WxAP 

Weather Accident Prevention project 

WxR 

Weather Radar 

ZxlO 

computer 
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